View MAQ28140FD_8285361.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

ma28140 1/72 the ma28140 packet telecommand decoder (ptd) is a single-chip implementation of the core part of a telecommand decoder, manufactured using cmos-sos high performance, radiation hard, 1.5 m technology. the ptd is a full implementation of and fully compliant with the packet telecommand standard esa pss-04-107 and the telecommand decoder specification esa pss-04-151, these being derived from the corresponding ccsds standards. the ptd, which handles 6 nrz tc input channels, processes the following layers: coding layer transfer layer segmentation layer authentication layer command pulse distribution some of these layers have a telemetry reporting mechanism. the processed tc segment can be transferred to the application either serially or in parallel. clcwsa clcwca clcwda clcwsb clcwcb clcwdb cpdus far1s far2s au1s au2s tmc tmd prdy pbus(0-15) audis auext aust aubuf auend aur autsl ausbuf farbuf tcc0-5 tcs0-5 tca0-5 vdd gnd rfavn vclsb tmmod par resetn clk prior test mode conf seltc(0-2) decod ladr(0-10) ldat(0-7) rwn brqn bgrn ramcsn romcsn laccs lack cpdustn cpduen cpdudiv mapstn mapck mapdsr mapdtr mapdata mapadt ptd 14 12 1444442444443 123 144424443 123 123 telemetry interface parallel interface authentication interface trans- ponder interface power 144444244443 miscellaneous 144424443 local bus interface 142443 map interface 123 cpdu interface features single chip implementation of all tc decoder core functions built-in authentication unit built-in command pulse distribution unit core logic radiation hard to 1mrads (si) high seu immunity, latch-up free cmos-sos technology conforms to ccsds standards 6 nrz tc input channels 50kbps bit rate low power consumption single 5v supply -55 to +125 c operation ma28140 packet telecommand decoder replaces june 2000 version, ds3839 -6.1 ds3839 -7.0 september 2001 pin connections
ma28140 2/72 contents page front sheet ............................................................................ 1 1. introduction ....................................................................... 2 2. tc decoder subsystem overview .................................... 3 3. ptd architectural overview .............................................. 4 4. ptd functional description 4.1 coding layer ....................................................... 6 4.2 transfer layer ..................................................... 9 4.3 authentication layer .......................................... 15 4.4 segmentation layer ........................................... 21 4.5 cpdu ................................................................. 22 4.6 telemetry reporting .......................................... 24 5. ptd interfaces 5.1 physical channel interface ................................ 27 5.2 map interface .................................................... 27 5.3 telemetry interface ............................................ 30 5.4 parallel interface ................................................ 34 5.5 cpdu interface .................................................. 35 5.6 local bus interface ............................................ 36 5.7 memories ........................................................... 36 5.8 external authentication ...................................... 41 6. state after reset ............................................................. 42 7. signal description ........................................................... 44 8. electrical characteristics and ratings 8.1 dc parameters .................................................. 47 8.2 ac parameters .................................................. 48 9. package details 9.1 dimensions ........................................................ 65 9.2 pin assignment .................................................. 66 10. radiation tolerance ...................................................... 70 11. ordering information ..................................................... 70 12. synonyms ..................................................................... 71 references 1. packet telecommand standard esa pss-04-107, issue 2, april 92. 2. telecommand decoder specification esa pss-04-151, issue 1, september 93. 1. introduction this document is the data sheet of the packet telecommand decoder, henceforth called the ptd. the ptd is compatible with the esa pss-04-107 standard directly derived from the ccsds recommendations. this standard is described in references 1 and 2. the data sheet is based on both documents for the description of the protocol. nevertheless, it was impossible to include the whole reference documents in the data sheet, thus some specific points of the protocol or some descriptions of the recommended hardware implementation have not been included. the reader may find these points in the applicable documents. convention in this document the two conventions described in references 1 and 2 apply: 1. the first bit in the field to be transmitted (i.e. the most left justified bit when drawing a figure) is defined to be bit 0. when the field is used to express a binary value, the most significant bit (msb) shall be the first transmitted bit of the field (i.e. bit 0). msb ? first bit transmitted = msb note: some of the external interfaces have parallel busses (ladr, ldat, pbus, seltc) which have the opposite bit order specified, i.e. bit 0 is the least significant bit. 2. an 8-bit word (a byte) is called an octet. lsb n bit data field bit n-1 bit 0
ma28140 3/72 figure 1: block diagram of a tc decoder subsystem ptd external authentication unit telemetry i/f map demultiplexer i/f cpdu i/f ram authentication configuration rom back-up power supply command pulses (256 max) serial data link (62 max) local bus clock transponder i/f tc input nrz or psk (6 max) 2. tc decoder subsystem overview an esa/ccsds telecommand decoder subsystem including the ptd and fulfilling the receiving-end functions established in the packet telecommand standard (ref 1) is shown in figure 1. the ptd requires the following additional hardware to fulfil the requirements of the telecommand decoder specification (ref 2): ? transponder i/f including demodulators for psk tc inputs. ? telemetry i/f. the telemetry reporting signals can be directly connected to a virtual channel multiplexer (ref 3). ? command pulse distribution unit i/f. this function performs decoding of commands present on the local bus and power amplification. the ptd asic associated with the cpdu i/f can manage 256 pulse outputs. ? map demultiplexer i/f. this interface is composed of a demultiplexer to provide the tc segment data to various data management system interfaces. the demultiplexer is controlled by the map data present on the local bus. the ptd asic can manage 62 different serial data interfaces (63 if au is disabled). ? memories. there are 2 different memories: - ram (2kx8) used to store the received tc data and protocol variables (programme authentication key for instance) and eventually to store the tc segment available for further processing by the data management system. if this memory is used to store the recovery lac counter (authentication function), it must be a non-volatile memory. - rom (1kx8) divided in two parts: - configuration part, used to provide the mission specific data. - authentication part, used to provide the fixed authentication key. ? external authentication unit (optional). although an au is implemented in the ptd, it is also possible to use an external au if the mission requires a different authentication algorithm. this external unit accesses the ram in order to authenticate a tc segment.
ma28140 4/72 3. ptd architectural overview figure 2 describes the ptd functional architecture which features 7 major blocks described below. figure 3 shows the ccsds protocol layer architecture. the ptd deals with the coding layer, the transfer layer, the authentication layer, the segmentation layer and a part of the packetisation layer of the ccsds protocol. coding layer block the coding layer block multiplexes the 6 physical tc channel inputs and fulfils the coding layer function described in section 5 of ref.1. the main tasks performed by the ptd at this level are: ? start sequence detection and selection of the first active tc input. ? codeblock error detection and correction. ? valid codeblock transfer to the above layer. ? generation of part of the far and clcw status. transfer layer block this level is concerned with the processing of the frames received from the coding layer and fulfils the transfer layer function described in section 6 of ref.1. at this level, the ptd performs the following tasks: ? clean frame validation. ? legal frame validation. ? frame analysis report mechanism. ? reporting word (16 bit clcw and part of 32 bit far) generation. authentication unit block this block (which is optional and can be disabled permanently or during flight) is concerned with the segment data protection, it enables the spacecraft to authenticate the received data. the authentication concept is the plain text with appended signature approach, described in section 8 of ref. 2. in the ptd architecture this function is implemented on chip. however, a specific interface allows authentication to be performed externally - if another coding algorithm is to be used, the on-chip block can be disabled and an external authentication system can be used. the block generates a reporting word (authentication status = 80 bits) and part of the 32 bit far. segmentation layer block this block implements only some of the segmentation layer functions described in section 7 of ref.1. its purpose is to manage the back-end buffer shared with the farm-1 block of the transfer layer and to implement the map interface in order to demultiplex (with external hardware) the segments dedicated to the different spacecraft applications. coding layer block clean frame validation block legal frame validation block farm-1 block segmentation layer block command pulse distribution unit clk data active 6 6 6 far7...12 far13...15 far18...20 far1...3 far4...6 far16,17 far1...3 clcw0...15 transfer layer bus controller adr control data authentication unit internal bus 11 ad ctl 8 data 6447448 external bus aus0...79 far28...30 far21...26 cpdus0...15 map interface telemetry module cpdus clcw far aus tm interface figure 2: ptd internal architecture
ma28140 5/72 f igure 3: ccsds protocol layer architecture acquisition sequence 16 octets first cltu 306 octets idle sequence min. 1 octet last cltu 34 octets idle sequence (optional) codeblock no.1 codeblock no.2 codeblock no.36 codeblock no.37 start sequence infor- mation error control e.c. e.c. e.c. fill e.c. tail sequence 111318 4 7 7 1 7 2 frame header 5 frame data field 249 (max.) frame error control 2 frame header 5 frame data field 9 frame error control 2 segment header 1 octet first packet segment 248 octets segment header 1 last packet segment 8 packet error control packet data packet header example : 256 octets packetisation layer segmentation layer transfer layer coding layer (codeblock length = 8 octets) physical layer (esa plop-2) command pulse distribution unit the cpdu is integrated into the ptd ensuring higher reliability for this critical function (direct telecommand for spacecraft reconfiguration) than if implemented in an external chip. the critical commands executed by the cpdu are received in specific packets. the cpdu responds to the map identifier 0, and to a mission dependent application process identifier (stored in rom). no segmentation is accepted, the commands must be contained in an unsegmented package. the unit generates a reporting word (cpdu status = 16 bits). bus controller this block is the interface between external memories and on chip modules. its different functions are: ? address decoding. ? internal and external bus access arbitration. telemetry module this block is the interface with the telemetry subsystem. it manages the data report storage using double buffered registers.
ma28140 6/72 4. ptd functional description 4.1 coding layer overview of the layer the coding layer provides the forward error correction capability and synchronisation services used by the transfer layer. each transfer frame is encoded/embedded in one cltu (command link transmission unit), which is the protocol-data unit of the coding layer. at the receiving end of the coding layer, a ?irty?symbol stream (plus control information on whether the physical channel is active or inactive) is received from the layer below. searching for the start sequence, the coding layer finds the beginning of a cltu and decodes the tc codeblocks. as long as no errors are detected, or errors are detected and corrected, the coding layer passes ?lean?octets of data to the transfer layer. should any codeblock contain an uncorrectable error, this codeblock is abandoned and considered as tail sequence, no further data is passed to the layer above and the coding layer returns to a start sequence searching mode until it detects one. the coding layer also generates part of the clcw and far status. the ptd can handle up to 6 tc input interfaces, the data bit rate on these inputs should not exceed 50 kbits per second when using the authentication unit. if the authenication unit is not used the symbol rate could exceed 200kbits/sec (not guaranteed). standard data structures within the layer a cltu is made up of three distinct protocol data elements: - one 16-bit start sequence, - one or more tc codeblocks of a fixed length of 8 octets to encode the protocol data unit from the layer above, - one tail sequence of length equal to that of the tc codeblock, i.e. 8 octets. the start sequence marks the beginning of the tc codeblock field within a cltu. it consists of a 16-bit synchronisation pattern represented in hexadecimal as eb90, where the first transmitted octet is eb. the tc codeblock field consists of one or more tc codeblocks. the codeblock length of received data is fixed and set to 8 octets (information field: 7 octets). the tail sequence marks the end of the tc codeblock field within a cltu. the length of the tail sequence is that of a tc codeblock. reference 1 specifies that its pattern should be alternating ?eros?and ?nes? ending with a ?ne?(55 .... 55 in hexadecimal), but any double error codeblock, or single error codeblock with filler bit equal to 1 will be interpreted as tail sequence by the ptd. synchronization and tc input selection synchronization is performed by searching for the start sequence simultaneously on all active tc inputs. the start sequence detection allows one bit error anywhere in the 16-bit pattern. furthermore due to nrz coding ambiguity on the incoming bit stream, it is possible to detect the inverted start sequence pattern in order to choose between positive or negative representation for further nrz data processing. if an inverted start sequence is detected, the following bit stream is inverted until the tail sequence is encountered. two different modes to perform the tc channel selection are supported, selectable with the prior configuration input: standard mode (prior = 0), in which all tc inputs tc0 to tc5 have the same priority, and the search for a start sequence is performed on all active tc channels simultaneously. priority mode (prior = 1), in which two inputs are assigned an absolute priority. note: this mode is not compliant with ref. 1, and is intended for applications with specific requirements on unconditional access to the tc decoder. if this mode is used, a thorough analysis of potential failure modes and the built-in timeout mechanisms is recommended. standard mode the tc input selection locks the selection multiplexer on the first tc channel where the start sequence is found. the selection mechanism is restarted once a tail sequence or a codeblock rejection has been detected. furthermore, as a protection mechanism in case of rf receiver breakdown, a timeout mechanism is provided; if the tc channel clock is not detected during a certain time, the tc selection mechanism is reactivated in order not to remain lacked on a channel without a clock signal. the timeout value between two successive edges of the tc channel clock is: 3932160 tck < tc clock timeout < 4587520 tck, with tck being the system clock period. with a system clock frequency fck of 4mhz this equals 0.98s ma28140 7/72 priority mode in this mode two inputs have priority, according to the following rule: tc0 > tc1 > tc2 = tc3 = tc4 = tc5. when neither the tc0 input nor the tc1 input is active, the selection between the inputs tc2 to tc5 is performed as in the standard mode. as soon as the tc active signal of tc0 is asserted, this tc input is selected, and the 5 other channels are inhibited. in case another input was already selected and receiving data, it is abandoned. the tc0 input remains selected until one of the following events: a1: its tc active signal becomes inactive, or b1: its bit clock has not been received for a period equal to the tc clock timeout, or c1: no start sequence has been detected for a period equal to the tc active timeout, or d1: a tail sequence or a codeblock rejection has occurred. upon events (a1) and (d1), the selection logic returns to the search state. upon events (b1) and (c1), the tc0 input is ignored (i.e. considered inactive) until the event (a1) occurs. when the tc0 input is inactive (including the case of a timeout as described above), as soon as the tc active signal of tc1 is asserted, this tc input is selected, and the lower priority inputs tc2 to tc5 are inhibited. in case any of these inputs was already selected and receiving data, it is abandoned. the tcl input remains selected until one of the following events. a2: its tc active signal, becomes inactive, or b2: its bit clock has not been received for a period equal to the tc clack timeout, or c2: no start sequence has been detected for a period equal to the tc active timeout, or d2: a tail sequence or a codeblock rejection has occurred, or e2: the tco active signal is asserted. upon events (a2) and (d2), the selection logic returns to the search state. upon events (b2) and (c2), the selection logic ignores the tc1 input until event (a2) occurs. upon event (e2) the tcl input is inhibited and the tc0 input is selected as previously described. the tc clock timeout value between two successive edges of the tc channel clock is: 3932160 t ck < tc clock timeout < 4587520 t ck . with a system clock frequency f ck of 4 mhz this equals 0.98s ma28140 8/72 codeblock transfer is performed in a serial way to the above layer (transfer layer). two indication signals are provided to the above layer - one indicating the whole frame duration, the other asserted each time a 7 octets block is being transferred. the following rules apply to the data transfer between the coding layer and the transfer layer: ? when the first candidate codeblock is affected by an event e4 or by an event e2, the cltu is abandoned. no candidate frame is transferred to the transfer layer. ? when the first candidate codeblock is found to be error free, or if it contained one error which has been corrected, its information octets (i.e. 7 octets) are transferred to the transfer layer. the decoding of the cltu continues until one of the following events occurs: 1- when an event e4 (codeblock rejection) occurs for any of the 37 possible candidate codeblocks the decoder returns to the search state s2 with the following actions: - the codeblock is abandoned - no information from that codeblock is transferred to the layer above - the coding layer indicates to the transfer layer the end of transfer of the candidate frame. 2- when an event e2 (channel deactivation) occurs the decoder returns to the inactive state (for the channel) with the following actions: - the cltu is aborted, - the cltu is reported as abandoned, - a signal is sent to the transfer layer to indicate that the entire block of octets making up the candidate frame must be erased. 3- when an event e2(b) (cltu error) occurs, the decoder returns to the search state with the following actions: - the cltu is aborted, - the cltu is reported as abandoned, - a signal is sent to the transfer layer to indicate that the entire block of octets making up the candidate frame must be erased. a cltu error occurs in the following cases: - more than 37 codeblocks have been accepted in the cltu, - a timeout on the tc clock signal occurs, - activity on a channel having higher priority is detected in priority mode. the decod output is activated when the cltu decoder state is s3. state number state name state definition s1 inactive all telecommand channels are inactive ( no bit lock is achieved ) or no bit modulation is detected. s2 search incomin g bit stream is searched, bit b y bit, for the start se q uence pattern. s3 decode codeblo cks, which are either free of error or which can be corrected, are received and decoded, and their information octets are transferred to the la y er above event number event name event definition e1 channel activation bit modulation is detected and bit lock is achieved: telecommand bit stream is present e2 ( a ) ( c ) ( b ) channel deactivation cltu error deactivation of the tc active si g nal more than 37 codeblo cks accepted in the cltu or timeout on the tc clock si g nal or activit y on a channel havin g hi g her priorit y in priorit y mode e3 start sequence found the start se q uence pattern has been detected, si g nallin g the be g innin g of the first codeblock of the cltu e4 codeblock rejection a codeblock is found uncorrectable ( erroneous codeblock or tail se q uence ) . no information octet from this codeblock is transferred to the la y er above
ma28140 9/72 4.2 transfer layer overview of the layer the transfer layer implements the following sublayers: - the frame error control sublayer which ensures that only clean frames are transferred to the sublayer above by using a crc error syndrome verification. - the frame header sublayer verifies the conformity of the relevant frame header fields by using the legal frame validation process before passing the frame to the farm1. - the frame acceptance and reporting mechanism one or farm1 ensures that frames are processed in the correct sequence. there are three types of tc transfer frames: - two types for the sequence-controlled service: ad and bc frames - one type for the expedited service: bd frames the sequence-controlled service is used for normal spacecraft communications. it concerns essentially tc transfer frames carrying tc segments: the ad frames. to configure the ad machine, special control frames are used called bc frames. the expedited service is used for recovery in the absence of the telemetry downlink or during unexpected situations. it is only concerned with tc transfer frames carrying tc segments: the bd frames. standard data structures within the layer the major fields of the tc transfer frame are shown below: frame header the structure of the frame header is given below: a description of the fields of the frame header is given below: ? version number, reserved field a and reserved field b should always be 00 (ref 1). ? bypass flag and control command flags. their values are given in the next table: ? spacecraft identifier. this field provides the identification of the spacecraft being commanded. 5 octets 1 to 249 octets 2 octets frame header frame data field frame error control field ? virtual channel identifier. it is used as a spacecraft sub- identifier. it can provide an identification of the spacecraft telecommand chain selected for operating the spacecraft. ? frame length. this field specifies the number of octets contained within the entire tc transfer frame: field value = (total number of octets) - 1 ? frame sequence number. this number is denoted as n(s). it is set to different values: - for ad frames it should be set to the transmitter frame sequence number and it is compared to the receiver frame sequence number v(r) stored in the ptd, to control the transfer of a sequence of frames (see the farm-1 process) - for bc and bd frames it should be set to all zeros. except for the bypass and control command flags, the values of the first three header octets are programmed in the external rom. in the abbreviations ad, bd and bc, a stands for acceptance check of n(s), b stands for bypass of a, c stands for control and d stands for data. ac is an illegal combination because control commands cannot reliably use a transfer service which they are meant to modify. frame data field the frame data field is of variable length from a minimum of 1 octet to a maximum of 249 octets. when the frame is a data frame (type ad or bd), it contains a tc segment. when the frame is a bc frame, this field can contain 2 control commands to configure the farm-1 process: ? the unlock command. the farm-1 has a built in mechanism which will go into a lockout state whenever it receives a type-ad frame containing a frame sequence number n(s) outside the limits of the farm-1 sliding window. the unlock command provides a mechanism to reset the lockout condition. the unlock command is encoded as a single octet with the value: 00000000. 2 octets 1 octet 1 octet 1 octet version number bypass flag control command flag reserved field a spacecraft id virtual channel id reserved field b frame length frame sequence number 2112106288 ? the set v(r) command. the set v(r) command allows v(r) to be preset to any desired value. the set v(r) command is encoded as three octets with the values: 10000010 00000000 xxxxxxxx the value to be set into v(r) is stored in the third octet. frame error field the frame error field is a mandatory 16-bit field which occupies the two trailing octets of the tc transfer frame. it is a cyclic redundant code (crc) generated with the polynom x 16 +x 12 + x 5 +1 with the shift register being initialised to all ones before processing each frame (refer to ref 2 for a complete description of this field). the crc is only used for error detection by the frame and not for error correction. bypass flag control command flag interpretation 0 0 ad frames 0 1 illegal 1 0 bd frames 1 1 bc frames
ma28140 10/72 standard procedures within the layer the clean frame validation process on receiving a new frame, the clean frame validation process performs the following tasks: - the number of octets in the frame is checked to be greater than 7 octets, - the transfer frame is assumed to be a version 1 frame, - the frame length field is checked to be compliant with the real number of octets of the frame, - the number of fill octets is verified to be minimum zero and maximum six, - the fill octets are removed, - the crc error syndrome verification is carried out. all candidate frames passing all the preceding validation checks are declared clean and transferred immediately to the legal frame validation process. frames failing any of the preceding tests are declared dirty and are erased. the legal frame validation process on receiving a clean frame, the legal frame validation process performs the following validation checks: - the version number is checked to be as defined in the rom, - the reserved fields a and b are checked to be as defined in the rom, - the value of the spacecraft id is checked to be as defined in the rom, - the value of the virtual channel id is checked to be as defined in the rom and by the vclsb input, - the bypass and control command flags must combine legally, - the bc frames must contain a valid control command (either unlock or set v(r)), - for a bc or bd frame the frame sequence number field must be set to all zeros. the lsb of the vc id is indirectly defined from a dedicated pin vclsb; it allows easy configuring of a pair of redundant tc decoders. - vclsb = 1: the vc id lsb read from the rom is inverted. - vclsb = 0: the vc id lsb read from the rom is not inverted. all candidate frames passing all the preceding validation checks are declared legal and transferred immediately to the farm-1 process. frames failing any of the preceding tests are declared illegal and erased. the farm-1 process the farm-1 variables the frame acceptance and reporting mechanism (farm-1) is described by a finite state machine represented by the farm-1 state table. the farm-1 maintains a set of variables which are described below: ? the state. this may be one of the following: - open (s1) - wait (s2) - lockout (s3) this variable represents the state of the farm-1 automaton. in open state, the farm-1 accepts frames and passes them to the above layer. in wait state, there is no buffer space available in which to place any further received data of type ad. the protocols leaves the wait state upon receipt of a buffer release signal from the higher layer. lockout is entered if the protocol machine detects an error. it is a safe state in that no user data (ad frames) will be accepted or transferred to the higher layer. the only accepted data frames are the bd frames, but even in this case the protocol machine remains in lockout state. the protocol machine leaves the lockout state upon receipt of an unlock control command. ? the lockout flag. this is set to 1 whenever the protocol is in the lockout state. ? the wait flag. this is set to 1 whenever the protocol is in wait state. ? the retransmit flag. this is set to 1 whenever the protocol machine knows that an ad frame has been lost in transmission or has been discarded because there was no buffer space available. this flag is reset to 0 upon the successful receipt of a frame with n(s)=v(r), the receipt of a set v(r) control command (unless in lockout state) or receipt of an unlock control command. ? farm b counter. this is incremented whenever a valid bd or bc frame arrives. this counter is a 2 bit wraparound counter. ? receiver frame sequence number v(r). this records the value of n(s) expected to be seen in the next ad frame. ? the buffer management variable. the ptd maintains a flag indicating the number of the back end buffer. the aubuf output pin provides the value of this flag (the back end and front end buffers are represented in figure 6). the number of the tc channel on which the data stored in the back-end buffer has been received is provided on the output pins (seltc2-0). ? farm sliding window variables. the purpose of these are to protect farm-1 against the unauthorised transfer of a sequence of frames such that the frame sequence number n(s) of one or more of these frames will exceed the current value of the v(r) counter. the farm sliding window concept applies only to ad frames. the farm sliding window is defined in terms of two variables: - the width of the positive part referred to as pw - the width of the negative part referred to as nw the farm positive window area starts with v(r) and extends pw frames in the positive direction. the farm negative window starts at v(r) - 1 and extends nw frames in the negative direction.
ma28140 11/72 figure 5: the farm sliding window concept n(s)=v(r)+1 n(s)=v(r) n(s)=v(r)+pw-1 n(s)=v(r)-nw n(s)=v(r)-1 discard frame & set retransmit flag discard frame & go to lockout state discard frame accept frame & set v(r)=v(r)+1 positive window area = pw lockout area = 256-w negative window area = nw a frame sequence number n(s) falls outside the farm sliding window i.e. in the lockout area when: n(s)>v(r)+pw-1 n(s)v(r) and n(s) v(r)+pw-1 the frame is in the positive window and does not contain the expected frame sequence number. the frame is discarded and the retransmit flag is set. ? third case n(s) ma28140 12/72 the farm-1 process description at the user end of the farm-1 process the tc segments are delivered as a buffer of accepted data. no distinction is made between a tc segment delivered by means of an ad frame and one delivered by a bd frame. however, the management of the common farm-1 back end buffer is affected as follows: ? bd frames: when a frame of this type is accepted by the farm-1, the tc segment it contains shall be placed in the back end buffer of the farm-1 even if this buffer still contains data (partially read or not ) in which case this data will be erased, an abort signal sent to the segment layer to signal the erasure and the new data signalled as arrived. this implies an event e10. ? ad frames: when a frame of this type is accepted by the farm-1, the tc segment it contains is placed in the back end buffer of the farm- 1 only when the buffer is available (empty). if the buffer still contains data, the newly arrived frame is discarded (erased) as shown by the farm-1 state table (event e2 in table 1). the definitions used in the farm-1 state table are listed below: ? valid frame arrives means that the legal frame validation sublayer has placed a legal frame in the front-end buffer. if the frame is a data frame (ad or bd) and if the farm- 1 accepts it, the back end buffer is allocated for the data. ? accept for an ad frame is subject to a buffer available signal. when no back end buffer is available (event e2) the frame is discarded. the data is then made available for the authentication layer, or the segmentation layer if authentication is disabled. ? accept for a bd frame means that the tc segment is placed in the back end buffer even when this buffer still contains data, in which case this previous data is erased (event e10). the wait concept does not apply to bd frames. the data is available for the authentication layer, or the segmentation layer if authentication is disabled. state name open wait lockout main feature of state normal state to accept frames wait flag is on lockout flag is on state number (s1) s(2) s(3) event conditions event number open wait lockout n(s)=v(r) a buffer is available for this frame e1 accept frame, v(r):=v(r)+1r etransmit flag:=0 (s1) not applicable discard (s3) valid ad frame arrives n(s)=v(r) no buffer is available for this frame e2 discard, retransmit flag:=1, wait flag:=1 (s2) discard (s2) discard (s3) n(s)>v(r) n(s) < v(r) i.e. inside part of sliding n(s)< and +pw-1 positive window and >v(r) e3 discard, retransmit flag:=1 (s1) discard (s2) discard (s3) table 1: the farm-1 state table
ma28140 13/72 event conditions event number open wait lockout (cont') valid n(s) v(r)-nw i.e. inside negative part of sliding window e4 discard (s1) discard (s2) discard (s3) ad frame arrives n(s)>v(r)+pw-1 and n(s) ma28140 14/72 buffer management once the data is validated (clean, legal and frame validation processes passed), it is transferred from the front- end buffer to the back-end buffer for use by the segmentation layer. only one back-end buffer is managed by the ptd. this mechanism is depicted in figure 6 below: figure 6: buffer management front end buffer segment n segment n-1 coding and transfer layers segmentation layer cpdu back end buffer segment n-1 cpdu buffer applications cpdu i/f n segment reception back end buffer segment n segment n+1 coding and transfer layers segmentation layer cpdu front end buffer segment n cpdu buffer applications cpdu i/f n+1 segment reception
ma28140 15/72 4.3 authentication layer structure of the authenticated segments the tc segment is the protocol data unit of the segmentation layer. the general format of an authenticated tc segment is specified in section 10 of ref.1. the particular format of an authenticated tc segment for the ptd is the following: (a) the length of the signature field of the authentication tail is 5 octets. (b) the length of the authentication tail is 9 octets (5 octets for the signature + 4 octets for the lac); the maximum length of the tc segment is 249 octets (segment header (1 octet) + segment data field (239 octets) + authentication tail (9 octets)), and its minimum length 10 octets (segment header (1 octet) + authentication tail (9 octets)). the segment trailer is optional and has a fixed length of 9 octets. the following table summarizes the management of the segment trailer. the selection of maps that are deemed to carry authenticated tc segments takes into account the possibility to associate map ids in pairs when packet re-assembly is required. therefore, authenticated maps are selected by pairs, using the 5 lsbs of the map identifier field of the segment header. the selection mechanism is such that it will point at the last pair of map identifiers (counting upwards from map 0) that carries authenticated segments. the value identifying this particular pair of identifiers is called the authenticated map id pointer and is stored in rom. for example, selecting map 4 (i.e. authenticated map id pointer = 4) means that the first 5 pairs of maps (i.e. map 0 and 32, map 1 and 33, map 2 and 34, map 3 and 35, map 4 and 36) are expected to carry authenticated tc segments. overview of the layer this optional layer is implemented on-chip but a connection to an external authentication unit is also implemented in case another implementation is desired. the choice of the au is done by means of a dedicated configuration input auext: ? auext = 1: the internal au is disabled and the external au is used, ? auext = 0: the internal au is used and the external au is disabled. map 63 is reserved for au configuration commands when authentication is disabled. it is possible to bypass this layer (when no authentication is required) by means of a dedicated configuration input audis. in this case, segments are passed directly to the segmentation layer .the values of the audis pin are: ? audis = 1: the internal or external au is disabled, ? audis = 0: the internal or external au is enabled. when the au is disabled, the tc segment does not have an au tail (the last nine octets are not deleted), the authenticated map id pointer has no meaning and map 63 is considered as a standard map (the data is output on map number 63 without removing the au tail). an 80 bit length status, aus, is generated by this block and fetched by the telemetry system in order to send it back to the ground segment. the authentication processor the authentication method specified in references 1 and 2 consists of generating a 40-bit digital signature using a transformation under a secret key applied to the tc segment. this authentication signature is appended to the tc segment and guarantees to the recipient that the tc segment is authentic with respect to its sender and its contents. an incoming tc segment is authenticated by performing the same transformation made by the transmitting end, and by comparing the received signature with the onboard-generated one. a functional diagram of the authentication processor is shown below. there are four main parts: - the hashing function; - the hard knapsack; - the deletion box; - the signature comparator. they are described in the next four subsections. not apparent on the functional diagram of figure 7 is the organisation of the secret authentication keys stored in the authentication processor. this is described in the section on au control commands on page 18. type of authentication type of frame segment trailer internal au authenticated frame segment trailer (9 octets length) not authenticated frame no segment trailer external au authenticated frame segment trailer (9 octets length) if autsl=0, no segment trailer if autsl=1 not authenticated frame no segment trailer au disable all no segment trailer segment header segment data fi eld segment trai ler sequence flags 2 bits map identifier 6 bits variable (optional) 9 octets <----------------1 octet ------------><----- from 9 to 248 octets ------>
ma28140 16/72 the hashing function one purpose of the hashing function is to compress the variable amount of data bits constituted by the extended message x into a pre-signature p of fixed length (60 bits). the device realising the hashing function is a 60-bit linear feedback shift register (lfsr), as shown in figure 8. the 60 feedback coefficients c0, c1,......,c59 are part of the authentication key. the lfsr is initialised to the 60-bit value p = 1000....000 (where bit p0 = 1) before the process of each authenticated tc segment begins. p will be the value in the lfsr after the last bit of the variable-length extended message x has been shifted in. the extended message x (x = [m,l,z]) consists of the following data elements, placed one after the other in that order: - the received message m, i.e., the tc segment (variable from 1 to 240 octets) without the authentication tail; - the received lac value l, i.e., 4 octets (2 bits of lac id, plus 30 bits of lac count); - three octets of virtual fill z, consisting of 24 zeros. the purpose of the 24 bits of virtual fill is to ensure that the hashing function is provided with a minimum of data bits. the 24 bits of virtual fill z are generated by the ptd. note that since m (the tc segment) cannot be equal to zero, the total length of an authenticated tc segment (i.e., [m,l,s]) cannot be smaller than 10 octets (segment header (1 octet) + authentication tail (9 octets)). anything smaller than 10 octets is rejected as being too short. the hard knapsack the purpose of the hard knapsack is to ensure that it is not possible to deduce the presignature p from the signature s. the hard knapsack is based on the concept of the modular knapsack. it consists of 60 weights (numbered from w0 to w59, each weight being 48 bits long) and is defined by the following transformation: j=59 s' = ( ? p j w j ) mod 2 48 j=0 where the bits pj of the presignature p select the corresponding weights w j of the knapsack. the result is the 48-bit knapsack sum s. the most significant bit of the sum is called s0. the deletion box the deletion box deletes the 8 least significant bits of the 48-bit knapsack sum s, i.e., bits s40 through s47. the result is the 40-bit authentication signature s (numbered from bit 0 to bit 39, as for signature s). the signature comparator the signature comparator compares the received 40-bit signature s with the onboard generated 40-bit signature s. figure 7: functional diagram of the authentication processor hashing function hard knapsack p deletion box s' s x signature comparator s s signature valid m l z tc segment (m, l, s)
ma28140 17/72 the authentication key the authentication key consists of: 60 x 48-bit hard knapsack weights = 2880 bits = 360 octets 60 x 1-bit hashing function coefficients = 60 bits = 8 octets full authentication key = 2940 bits = 368 octets the system includes two such 2940-bit keys: - a fixed, mission-unique authentication key, called the fixed key; - an in-flight programmable authentication key, called the programmable key. (a) fixed key the fixed key is required for start-up and emergency (recovery) operations. the fixed key is stored in the external rom as part of the mission-specific data. (b) programmable key the programmable key is required for all normal operations. the contents of the programmable key reside in the ram where it can be modified by means of authentication control commands specifically defined for that purpose. the format of these change programmable key block control commands, which are specified in the section on au control commands (page 18), allows any 5-octet block to be modified starting at any of the 368 octet boundaries. the supervisor the supervisor consists of four main parts: - the logical authentication channel (lac) registers; - the final authorisation function; - the control command processor; - the deletion function. they are briefly described in the next four subsections. the lac counters a lac counter is basically a 30-bit counter which is used to associate every tc segment with an authentication sequence number. the purpose of this number is to protect the system against attacks by ensuring that identical tc segments will not have the same signature except at very large intervals of time. the lac counter is incremented by one every time a tc segment is successfully authenticated (and only then). the lac counter value used for authenticating each tc segment is uplinked with each signature. three lac registers are provided: - one principal lac register (lac id = 00); - one auxiliary lac register (lac id = 01); - one recovery lac register (lac id = 10). bits 0 and 1 of the lac are fixed in order to select the lac register to be used for the final authorisation of a tc segment. for what concerns the 30 bits of lac count (bits 2 through 31, where the lsb is bit 31), they are implemented as follows: - the principal and auxiliary lac counters have 30 bits. - the recovery lac counter has 8 bits (the lsbs 24-31) whereas the remaining 22 bits (2-23) are permanently set to 1. the final authorisation function when the received signature s of a tc segment compares with the onboard-generated signature s, the contents of the received lac count field is compared with the contents of the indicated lac register. if both contents are found equal, there are two cases: - the tc segment was transferred on a map to be authenticated with a map id lower or equal to the map id pointer. in this case, the tc segment is authorised for transfer to the segmentation layer. figure 8: realisation of the hashing function p (i) 0 c 0 p (i) 1 c 1 p (i) 2 c 2 p (i) 3 c 3 p (i) 59 c 59 x (i)
ma28140 18/72 - the tc segment was transferred on map 63 (i.e., map 111111), which is dedicated to the transfer of authentication control commands. in this case, the control command processor is authorised to further process the tc segment, which will never be transferred to the segmentation layer. in both cases, the contents of the indicated lac register is incremented by one. the control command processor the function of the control command processor is to execute the special tc segments called authentication control commands after being authorised by the final authorisation function. the formats of the various authentication control commands are specified in the section on au control commands next. any tc segment not conforming to the specified formats (i.e., both in length and in contents) are rejected and reported as not executable. the deletion function the deletion function deletes the authentication tail of all tc segments authorised by the final authorisation function. the complete authentication process is meant to be transparent to an observer placed at the receiving end of the segmentation layer. au control commands it is necessary to differentiate tc segments containing the authentication control commands required to reconfigure the au. this is done by allocating the tc segment header contents all ones to these particular segments, i.e.: - sequence flags set to 11 (unsegmented) - map id set to 111111 (map63) tc segments containing the authentication control commands shall always be authenticated. the formats of the authentication control commands are organised in three groups as follows: - one octet of tc segment header for all three groups. - one octet following the segment header to specify the control command identifier - zero, four or eight octets of control command data field, depending on the group. table 2 gives the complete list of authentication control commands, with group numbers, control command ids and command names. table 3 shows the format of the tc segment for each group, complete with authentication tail. each control command is specified in the next subsections. dummy control command the purpose of this command is to serve as nop (no operation) for testing purposes. after being authenticated, this control command will have no effect. however, since the au has authenticated the dummy segment, the contents of the lac register used during the authorisation process have been incremented and a telemetry report prepared accordingly. select key control commands (a) select fixed key the au selects the fixed key prior to authenticating the tc segment: - if authentication is successful, the fixed key remains selected. - if authentication is unsuccessful, the key previously in use remains selected. (b) select programmable key the au selects the programmable key for authentication of the tc segment: - if authentication is successful, the programmable key remains selected. - if authentication is unsuccessful, the key previously in use remains selected. load fixed key in programmable key memory control command this command reloads the fixed key set in the programmable key memory with a single command instruction. the key used for authenticating the tc segment containing the control command will be whatever key was selected in the au at the time the command was transmitted. set new lac count value control command the purpose of this control command is to set the value of one of the three programmable lac counters: principal, auxiliary or recovery with lac identifiers 00, 01 and 10 respectively. if the lac identifier is set to 11, the command is not executed and reported as not executable. as soon as the tc segment is authorised by the authentication process, the specified lac count value is forced into the selected lac register. note that the 22 msbs of the 30-bit recovery lac register are permanently set to all ones, therefore those same bits in a set new recovery lac count value control command are ignored by the au. the key used for authenticating the tc segment containing the control command will be whatever key was selected in the au at the time the command was transmitted.
ma28140 19/72 table 2: list of authentication control commands 1 octet 1 octet 9 octets segment header control command identifier authentication tail 11111111 00000*** lac+signature group 1 control command, 11 octets 1 octet 1 octet 4 octets 9 octets segment header control command identifier lac value to be set authentication tail 11111111 00001001 lac id 2 bits lac count 30 bits lac + signature group 2 control command, 15 octets group 3 control command, 19 octets table 3: formats of authentication control commands (full tc segment) 1 octet 1 octet 1 octet 7 octets 9 octets segment header control command identifier start address of new 40 bit keyblock key specific pattern to be encoded authentication tail 11111111 0000101* lac+signature group control command identifier (8 bits) co mmand name group 1 0000 0000 0000 0101 0000 0110 0000 0111 dummy selec t fixed key selec t pro grammable key lo ad fixed key in pro grammable key memo ry gro up 2 0000 1001 set new lac c o unt value group 3 0000 1010 0000 1011 c hange pro grammable key blo c k a c hange pro grammable key blo c k b
ma28140 20/72 change programmable key block control commands a and b two such control commands are provided to cover the full size of the programmable key: - command a concerns the first 256 octet boundaries. - command b concerns the last 112 octet boundaries. it is possible to load a 5-octet (40 bits) block starting from any of the 368 octet boundaries. any transmission using the unused boundaries of command b (from 113 to 255) is ignored and reported as non-executable. the key used for authenticating the tc segment containing one of these control commands will be whatever key was selected in the au at the time each control command was received. once the tc segment has been authorized by the authentication process, the tc segment, minus the 40-bit signature s (i.e. [m,l]) is complemented and passed once more through the signature-building process, i.e. through the authentication processor. the 24 bits of virtual fill z are inserted as before, i.e., they are not complemented, but remain all zeros. the result of the process is a 40-bit pseudo-signature which, instead of being sent to the signature comparator, is loaded in the programmable key memory, starting at the octet location indicated by the start address field, as follows: - bits 32 through 39 of pseudo-signature at the indicated octet location; - bits 24 through 31 of pseudo-signature at the next location (start address + 1); - and so on, until bits 0 through 7 are loaded at location start address + 4. any arbitary procedure can be used for changing the key, starting from any of the 368 octet boundaries. figure 9: organisation of the programmable key memory w0 (40 to 47) 40 47 000 200 w0 (32 to 39) 32 39 001 201 w0 (24 to 31) 24 31 002 202 w0 (16 to 23) 16 23 003 203 w0 (8 to 15) 815 004 204 w0 (0 to 7) 07 005 205 w1 (40 to 47) 40 47 006 206 w1 (32 to 39) 32 39 007 207 w42 (16 to 23) 16 23 255 2ff w42 (8 to 15) 815 000 300 w59 (0 to 7) 07 103 367 c (59 to 56) 59 56 104 368 c (55 to 48) 55 48 105 369 c (47 to 40) 47 40 106 36a c (39 to 32) 39 32 107 36b c (31 to 24) 31 24 108 36c c (23 to 16) 23 16 109 36d c (15 to 8) 15 8 110 36e c (7 to 0) 70 111 36f ram mapping address provided in the control command (decimal) bank a bank b note: bit 0 is the msb
ma28140 21/72 4.4 segmentation layer overview of the layer the segmentation layer provides the means to distribute several distinct streams of variable-length data units (e.g. the tc packets) to different applications by providing a number of service access points called the multiple access points (maps). the data flow on each stream can be controlled by the receiving application using handshake control. a tc segment consists of three distinct protocol data elements: - an 8-bit segment header, the purpose of which is to identify the map connection and flag the sequential position of the segment relative to the complete tc packet, - a segment data field, of maximum length 248 octets, which contains all or a portion of a tc packet, - the 9-octet segment trailer specific to authenticated segments is removed by the authentication layer. standard data structures within the layer the structure of the tc segment is given below: segment header the segment header is the first octet (octet 0) of the tc segment structure. the segment header is divided into two major fields as follows: - sequence flags (bits 0 & 1): this field is used by the segmentation protocol to indicate the sequential position of the segment relative to the complete data unit (e.g. the tc packet). the flags are interpreted as follows: when the flags are set to 11 this means that the tc segment data field contains an entire tc packet. except for the cpdu described in section 4.5, these flags are ignored by the ptd. - multiplexed access point (map) identifier: this 6-bit field enables up to 64 map connection addresses to be associated with a single virtual channel. the ptd supports map 1 to 63 as externally available maps. map 0 is dedicated to the cpdu. map 63, when au is enabled, is reserved for au commands; when the au is disabled, map 63 is processed by the segment layer like a standard map (see section 4.3). bit 0 (msb) bit 1 interpretation 0 1 first segment 0 0 continuation segment 1 0 last segment 1 1 unsegmented segment data field the segment data field may vary from 0 to 248 octets maximum. when the optional segment trailer is used, the maximum length of the segment data field will be reduced by 9 octets. standard procedures within the layer the following segmentation layer functions are implemented in the ptd: - the back-end buffer for the accepted tc segment. the back-end buffer is shared between the transfer layer and the segmentation layer. - the map interface. upon reception of a new segment the segment layer performs the following operations: - checks whether the segment is authenticated or not. - starts the au process if the segment is authenticated and if the au is not disabled. the segment layer waits for the completion of the au process (internal or external). a security mechanism is implemented, in case of au locking mechanism the user can stop the au process by activating the au disable signal. in this case, the segment layer stops waiting for the au completion process and the content of the back end buffer is lost. - checks if the frame is a cpdu command (map 0). in this case, the cpdu layer is activated and no data is output on the map interface. - checks if the frame is an au command (map 63) and the au is not disabled. in this case no data is output on the map interface. - for a map 1 to 62 and for map 63 if the au is disabled, the data is provided in serial or in parallel via the map interface. the map output frequency for serial map is selectable by reading a value associated with each map in the external rom (see section 5.2). segment header segment data field sequence flags 2 bits map identifier 6 bits variable <--------------- 1 octet ------------><- from 0 to 248 octets ->
ma28140 22/72 4.5 command pulse distribution unit general requirements the cpdu is a simple unit that is solely accessible from ground. the aim of this unit is to generate pulses to drive certain actuators (e.g. relays). the cpdu is identified by the application process identifier placed in the tc packet header. the application identifier of the cpdu is programmable in rom at addresses 006 and 007. functional description the cpdu receives tc segments, each segment containing a complete tc packet. tc segments having a map equal to zero are carrying cpdu commands. it must be noted that if the internal au is enabled, map0 segments are always authenticated. when a new segment carrying cpdu commands has arrived, two cases are possible: - the cpdu is still executing previous cpdu commands. in this case, the incoming tc segment is ignored, whether it was transferred in an ad or bd transfer frame. - the cpdu is idle. the incoming tc segment is copied from the back end buffer to the cpdu buffer for checking and execution by the cpdu. an important point must be noted: there is no packetisation layer abort command associated with the cpdu. once it has accepted a tc packet, the cpdu cannot release it until all command instructions specified in that packet have been executed. the cpdu performs first the clean validation process which verifies the complete packet (crc, packet length, segmentation flags). if the clean validation process is successful, the cpdu performs the legal validation process, which checks the content of the packet headers. the result of the two previous verifications is reported in the 16 bits cpdu status. for a dirty or illegal cpdu packet, the cpdu buffer is erased. the execution of the cpdu commands is possible only if all the verifications succeed. checking the cpdu-specific tc packet the cpdu packet format is shown below: a short description of the fields of the cpdu packet is given below: - version number: 3-bit field occupying the 3 msbs of the packet header. to be compliant with ref.1, these 3 bits should be 000. - type bit: this bit identifies if the packet is telemetry type (type bit = 0) or telecommand type (type bit = 1). to be compliant with ref 1, this bit should be set to 1. - data field header flag: this indicates the presence (data field header flag = 1) or absence (data field header flag = 0) of a data field header within the packet data field. to be compliant with ref 1, this bit should be set to 0. - application process identifier: this field identifies the particular process to which the cpdu packet is sent. - sequence flags: this two-bit field indicates if the packet is a first, last or intermediate component of a higher layer data structure. for cpdu packets, these two bits shall be equal to 11. - packet sequence count: this 14-bit field allows a particular tc packet to be identified with respect to others occurring within a telecommand session. this field is reported in the cpdu status for clean and legal cpdu packets. - packet length: this field specifies the number of octets contained within the packet data field, by indicating the number of octets in data field minus 1. - packet data field: this field contains the cpdu commands and the crc for packet error control. packet header (48 bits) packet data field (variable) packet identification packet sequence control packet length data field header applic- ation data packet error con- trol version number 3 type 1 data field header flag 1 applicat- ion process id 11 sequence flags 2 packet name or sequence count 14 16 16 16 variable variable 16
ma28140 23/72 the cpdu packet is checked in two steps: the clean validation process and the legal validation process. the clean verification process performs the following tests: - correct crc (last two octets of the packet contain a 16-bit crc calculated using the same algorithm as used for the tc transfer frame, see section on transfer frame) to verify that there is no error in the packet. - the tc segment segmentation flags (in segment header) are equal to 11. - the cpdu packet length is checked to be an even number of octets, greater than or equal to 10 octets and less than or equal to 248 octets: 10 octets tc packet length = even number of octets 248 octets. the cpdu packet length is read from packet header octets 5 and 6. - consistency between the actual number of octets making up the cpdu packet and the packet length field. to achieve this, the packet header octet 5 is checked to be zero and the packet header octet 6 is checked to be consistent with the effective packet length. at this level, if the packet is found to be error-free, it is declared clean and the process continues. otherwise, the complete cpdu packet is erased. the legal verification process performs the lollowing tests on the packet header (see ref 1, section 8): - the first octet of the packet header (version number & type bit & data fields header flag & 3 msbs of application process identifier) is compared with the value programmed in rom at address 006. - the second octet (8 lsbs of application process identifier) is compared with the value programmed in rom at address 007. - in the third octet (sequence flags & 6 msbs of packet name or sequence count), only the sequence flags field is checked by the ptd to be equal to 11. the packet name or sequence count is not verified, it is only reported in the cpdu status. - the fourth octet (8 lsbs of packet name or sequence count) is not tested since the packet name or sequence count is not verified. it is only reported in the cpdu status. if the above check succeeds, the tc packet is declared legal and its application data (command instructions) read out and executed as described in the next subsection. if the check fails, the packet is erased. processing the application data the cpdu receives a segment from the segment layer and stores it for further processing in the cpdu buffer provided in ram. at the same time, the clean process is performed. this segment duplication is necessary due to delayed command execution. the duration of the transfer is equal to: td = nb * tacc where nb is the number of octets of the tc segment (including au tail), and tacc is the duration of three ram accesses read - write - read (the last read is used for computing the crc with data effectively stored in ram). tacc can be estimated to 20*tck (5 m s for a clock frequency of 4 mhz). the application data of the cpdu packet should consist of at least one command instruction in the form of one double octet, or several of such double-octet command instructions, up to the maximum capacity. each double octet should be formatted as follows: ? first octet: specifies one of 256 command pulse outputs. the command distribution shall be made by an external demultiplexer (256 possible command pulse outputs). ? second octet: specifies the duration of the command pulse to be issued on the specified output as follows: - the 5 msbs are ignored by the cpdu, - the 3 lsbs specify the duration of the command pulse, which is equal to about 2 x multiplied by d where x is the value of the 3 lsbs and d = 40960 clock periods for cpdudiv=0, d = 8192 clock periods for cpdudiv=1. (see section 5.5 for exact figures.) when there is more than one command instruction in the cpdu packet, each instruction is executed one after the other in the same sequence as in the packet. the maximum capacity of the cpdu packet is: ? 248 octets corresponding to 120 command instructions if the internal or external authentication unit is disabled (audis=1) or if the external authentication unit is enabled (auext=1 and audis=0) and autsl=1. ? 238 octets corresponding to 115 command instructions if the internal authentication unit is enabled (auext=0 and audis=0) or if the external authentication unit is enabled (auext=1 and audis=0) and autsl=0. for the calibrated pulses being output on the cpduen pin, the pulse amplification shall be made by external hardware. the cpdu provides a 16 bit status, cpdus, that can be fetched by the telemetry system. the different fields of the cpdu status are detailed later.
ma28140 24/72 4.6 telemetry reporting general description telemetry reporting is essential to the normal operation of the telecommand data communication system. data reports are not modified during telemetry readout. in particular they are not affected by the arrival of new report data. if the telemetry interface sampling rate is slower than the rate at which new data reports are generated, a double register mechanism ensures that the complete data report is read out. clcw status report the command link control word (clcw) is a standard reporting data structure of the packet telecommand system. it is a four-octet word generated by the spacecraft, the ptd generating only the 2 least significant octets of this clcw which are described hereafter. bits value meaning 0 (msb) no rf available 1 no bit lock 2 lock out 3 wait 4 retransmit 5,6 farm b counter 7 0 report type 8 - 15 (lsb) report value each clcw field is specified in the next paragraphs: ? no rf available. this field is dedicated to the physical layer, i.e. the rf transponders. when this field is 1, the rf physical connection is not available through any of the spacecraft transponders. when it is 0, the rf connection is available through at least one of the spacecraft transponders. this information is provided to the ptd by an input pin called rfavn. ? no bit lock. this field is dedicated to the physical layers, and monitors the presence of the spacecraft demodulation. when this field is 1, all the tc active signals (0 to 5) are zero at the ptd input pins. when it is 0, at least one of the tc active signals is set to 1. ? lockout flag. if 1, this field indicates that the farm- 1 is in the lockout state. ? wait flag. if 1, this field indicates that the farm- 1 is in a wait state. ? retransmit flag. if 1, this field indicates that an ad frame has been lost in transmission or has been discarded because there was no buffer space available. ? farm b counter. this 2 bit field contains a wraparound up-counter (modulo 4) of each tc frame of type bc or bd declared valid by the legal frame validation process, and therefore acceptable by the farm-1. ? report type. in the ptd it is always 0 in accordance with reference 1. ? report value. this field is maintained by the farm-1 and contains the next expected frame sequence number v(r). the first bit to be read in serial mode is bit 0 (msb). the interface for reading the clcw status is specified in section 5.3. cpdu status report the cpdu status report consists of 16 bits of status data formatted as follows: bits value meaning 0,1 00 cold start 01 last tc packet accepted legal 10 last tc packet accepted clean, but erased as not legal 11 last tc packet erased as not clean 2 - 15 (lsb) all 1 cold start all other packet sequence count (or values name) of last legal cpdu packet the first bit to be read out in serial mode is bit 0 (msb). legal and clean concepts are defined previously. the telemetry interface used to read out the cpdu status report is fully described in section 5.3. au status report the au status report consists of 80 bits (i.e. 10 octets) of status data formatted as follows: bits value meaning 0,1 00 permanently set to 00 2 - 31 current value of the contents of the principal lac counter. the lsb of the lac counter value is in bit 31 32,33 01 permanently set to 01 34 - 63 current value of the contents of the auxiliary lac counter. the lsb of the lac counter value is in bit 63 64 key in use by au: 0 fixed key in use 1 programmable key in use 65 - 71 0000000 permanently set to 0 (reserved for future use) 72 - 79 (lsb) current value of the 8 lsbs of the recovery lac counter. the lsb of the lac counter value is in bit 79. the first bit to be read in serial mode is bit 0 (msb). the au status report is implemented by using a double register mechanism located in the external ram. in the case of external au, the external au can write the au status in ram. the number of the buffer is given by the aus pin and the toggling mechanism of the au status buffer is locked by the ptd when the signal aust ( external au start) is high. the telemetry interface used to read the au status report is described in section 5.3.
ma28140 25/72 frame analysis report the far is required for proper testing and check-out of the tc decoder. the far consists of 32 bits of survey data formatted as follows: bi ts value meani ng 0 (msb) 1,2,3 4,5,6 7 - 12 13,14,15 16,17 18,19,20 21 - 26 27 28,29,30 0 1 000 001 010 011 100 101 110 111 000 001 010 011 100 101 110 111 xxxxxx xxx 00 01 10 11 xxx xxxxxx 0 000 001 010 011 status of survey data new survey data (or cold start) old survey data frame analysis note: the report of the lowest rank (i.e. of lowest 3-bit value) has precedence in case of conflicting states. abandoned cltu (see note 1) frame declared dirty frame declared illegal for one reason frame declared illegal for multiple reasons frame (ad) discarded because of lockout frame (ad) discarded because of wait frame (ad) discarded because of n(s) or v(r) frame (ad, bd or bc) accepted by farm-1 legal/illegal frame qualifier note: when a frame is declared illegal for multiple reasons, only the reason of the first rank (i.e. of lowest 3-bit value) is reported. the fields mentioned are those of the frame header. no illegal report (or cold start) error in fixed fields (version & reserved) illegal combination (ac) of bypass & control command flags wrong spacecraft id wrong vc id (because of bits 0 to 4 of id) wrong vc id (because of bit 5 of id) n(s) of bc or bd frame not set to all 0 wrong bc frame data format (not executable) count of accepted code blocks per cltu straight 6-bit binary count of correct or single-error-corrected codeblo cks in one cltu; (cold start value: 000000) count of si n gle-error corrections per cltu straight 3-bit binary count, saturates at maximum value, no roll over. (cold start value:000) legal frame qualifier (4 states) ad frame no report on legal frame (or cold start) bd frame bc frame selected channel input (maxi mum c apability : 6 i nputs) (cold start value : 111) last map a ddressed (64 maps) (cold start value : 111111) reserved by esa (set to 0) authenti cati on proc ess analysis no authentication report (or cold start) authori sed segment qualifier authorised data segment authorised (and executable) authentication control command authorised dummy segment received
ma28140 26/72 a few specific points need to be detailed: note 1: the abandoned cltu state (000) is used to indicate: ? the cold start ? a first tc codeblock of cltu was abandoned (erased) because of event 4 or event 2 ? an event e2(a) channel deactivation occurs (see section 4.1) ? an event e2(b) cltu error occurs (see section 4.1) in the case of an abandoned cltu the legal/lllegal frame qualifier (bits 4, 5, 6) is set to 000 and the legal frame qualifier (bits 16, 17) is set to no report on legal frame (01). note 2: the rejected segment qualifier in the authentication process analysis has the following prioritisation: ? 111 too short tc segment has the highest precedence, followed by ? 100 error in signature, followed by ? 101 error in lac, followed by ? 110 wrong format of au command or segmentation flags. the far is sampled and read by a telemetry interface described in section 5.3. bi ts value meani ng 31 (lsb) 100 101 110 111 0 rejected segment qualifier error in signature error in lac wrong format (not executable) of authorised authentication control command (includes segment header) wrong length of tc segment prior to being authenticated (authorised), i.e. length shorter than 10 octets set to 0
ma28140 27/72 5. ptd interfaces 5.1 physical channel interface each tc channel consists of 3 input lines: ? tcc i : symbol clock input ? tcs i : symbol stream input (nrz-l) ? tca i : channel active indication input the maximum symbol rate with guaranteed operation (using the internal au) on these channels is 50 kbps. for higher frequency, an incomplete au process may occur resulting in wrong signature calculation and thus rejected frames. without au the symbol rate could be 200 kbps (not guaranteed). at higher frequency, incorrect processing may occur due to insufficient time to perform memory accesses. the interface is composed of 6 tc channels. figure 10 below gives the timing associated with one of these 6 channels. for unused channels, the tca i signal should be connected to v ss , and the tcc i and tcs i signals to v dd . the decod output is activated when the cltu decoder state machine is in the decode state (see section 4.1). this output goes high following the detection of a start sequence, and goes low following a codeblock rejection or cltu error. 5.2 map interface the map interface allows the ptd to provide the on-board applications with the tc segments stored in the back-end buffer in the ram. it is possible to transfer full tc segments (including segment header and packet segment) with various lengths, from 1 octet to 249 octets. the first data output is the tc segment header. it is possible for an application to use either a serial or parallel interface to read this tc data. the choice between serial or parallel interface is made with the configuration input pin par as follows: ? par = 1; the parallel map interface is used (section 5.4) ? par = 0; the serial map interface is used the serial map interface consists of 5 signals. ? mapdsr, data set ready output, ? mapdtr, data terminal ready input, ? mapck, map clock output, ? mapdata, segment data output, ? mapadt, aborted data transfer output. figure 10: tc channel input timing
ma28140 28/72 in addition, the map interface provides the output signal mapstn, in order to save the map identifier present on the local data bus (ldat<7..0>) in an external latch. this map identifier is used to demultiplex the segment data toward the selected application. the mapstn signal can be controlled by the lack signal. mapdsr has no effect when mapdtr output is deasserted. the output frequency for each map is programmable and is defined in rom. for map number n, the address of the value x defining the map frequency is (hex) 100+n. the map output frequency is given by f=f ck /[2 x ], (x is coded on the 4 lsbs and its value varies from 1 to 13; for other values, the output frequency is f = f ck /2). for example for a ptd clock frequency of 4 mhz, setting the rom value to 4 will generate a map frequency of 250 khz. with a system clock frequency fck of 4 mhz, the mapck frequency can vary from 488 hz (x=13) to 2 mhz (x=1). the use of a too low map frequency compared to the tc clock frequency may lead to the activation of the wait flag if the map output of a previous frame is not finished when a new segment arrives. as a rule of thumb, in order to avoid the wait flag being asserted, the map frequency should be at least the tc input bit rate multiplied by 10 when fully variable segment size (by 2 if fixed length). figure 11 describes the serial interface in three different transfer situations. mapdsr mapdtr mapck mapdata mapadt ptd application par = 0 serial map interface note: the bit 0 is the msb and shall be transmitted first. figure 11: serial map interface n maximum value is 1991 corresponding to a tc segment of 249 octets.
ma28140 29/72 example of data transfer with data flow control. n maximum value is 1991 corresponding to a tc segment of 249 octets. note: for each mapdtr pulse one octet is transferred. note: the mapadt signal is asserted on octet boundaries of the map data being transferred. figure 11: serial map interface (continued)
ma28140 30/72 5.3 telemetry interface the telemetry interface allows four different reporting words to be retrieved. ? the command link control word (clcw), ? the command pulse distribution unit status (cpdus), ? the frame analysis report (far), ? the authentication unit status (aus). it is possible for an application to use either a serial or parallel interface to read these reports. the selection between serial or parallel interface is made with the configuration input pin par as follows: ? par = 1; the parallel tm interface is used ? par = 0; the serial tm interface is used the parallel interface is described in section 5.4. the parallel interface is useful for integrating subsystems comprising both the tc decoder and a processor, without cross-coupling after the tc decoders. the clcw has its own serial telemetry interface which is redundant in serial mode. the other three reports (cpdus, far, aus) can be fetched through a common serial interface (clock and data lines) using two or five different sample signals. the selection between using two or five sample signals is made with the configuration input pin tmmod as follows: ? tmmod = 0; the status (cpdus, far, aus) reports are fetched with 5 sample signals. ? tmmod = 1; the status (cpdus, far, aus) reports are fetched with 2 sample signals. both interfaces use the same tmc and tmd signals. when the parallel interface is selected it is not possible to use the tm (and map) serial interface, except for the clcwb interface which can be used in a serial mode even if the par signal is set to 1. the protocol for the serial interface is fully compliant with section 4.3 of ttc-b-01 (serial 16 bit digital channel). serial clcw interface the 16 bit command link control word (clcw) can be retrieved through this interface. the serial clcw interface is redundant in order to allow two separate redundant tm encoders to be connected to each tc decoder. figure 12 shows the serial clcw telemetry interface. the serial interface is implemented with 3 signal lines: ? clcwsa: status sample input, ? clcwca: status clock input, ? clcwda: status data output. the redundant serial clcw interface is identical with the nominal serial clcw interface using the 3 signals: ? clcwsb: status sample input, ? clcwcb: status clock input, ? clcwdb: status data output. note: the 0 bit is the msb and is transmitted first. figure 12: serial clcw telemetry interface clcwsa clcwca clcwda ptd application telemetry systems par = 0 clcw serial interface clcws i/f
ma28140 31/72 cpdu status report interface in 5 samples mode the 16 bit command pulse distribution unit status report can be retrieved through this interface. it is possible for an application to use either a serial or a parallel interface to read out this status report. the serial or parallel mode is selected with the par configuration pin of the ptd (see section 5.4). the serial interface in 5 samples mode uses 3 signal lines: ? cpdus: status sample input. ? tmc: status clock input, is also used for far and aus. ? tmd: status data output, is also used for far and aus. the sample signal cpdus needs to be activated only once to fetch the entire cpdus word. cpdus, far1s, far2s, aus1s and au2s cannot be asserted simultaneously. if cpdus, far1s, far2s, aus1s and au2s are not asserted, activating the tmc signal will generate invalid data on the tmd output. if the cpdu status report interface is not used, the cpdus signal should be connected to v dd . figure 13 below describes the cpdu telemetry serial interface. serial far status report interface in 5 samples mode the 32 bit frame analysis report can be retrieved through this interface. it is possible for an application to use either a serial or a parallel interface to read out this status report. the serial or parallel mode is selected with the par configuration pin of the ptd (see section 5.4). the serial interface in 5 samples mode uses 4 signal lines: ? far1s: first status sample input, ? far2s: second status sample input, ? tmc: status clock input, is also used for cpdus and aus, ? tmd: status data output, is also used for cpdus and aus. the sample signal clcwsa should be activated only once to fetch the entire clcw word. the serial clcw interface has been designed to allow the vcm device specified in reference 3 to automatically retrieve the clcws without any additional components being required. if one of the clcw interfaces is not used, the following signals clcwsx and clcwcx should be connected to v dd . activating the clcwca (clcwcb) signal when clcwsa (or clcwsb) is deasserted, will generate invalid data output on clcwda (or clcwdb). note: the 0 bit is the msb and is transmitted first. figure 13: cpdu telemetry serial interface cpdus tmc tmd ptd application telemetry systems par = 0 clcw status report serial interface cpdus i/f
ma28140 32/72 the sample signals far1s and far2s should be asserted to fetch the 32 bits of far. cpdus, far1s, far2s, aus1s and au2s cannot be asserted simultaneously. if cpdus, far1s, far2s, aus1s and au2s are not asserted, activating the tmc signal will generate invalid data on the tmd output. if the far status report interface is not used, the far1s and far2s signals should be connected to v dd . figure 14 describes the far telemetry serial interface. serial au status interface in 5 samples mode the 80 bit authentication unit status report can be retrieved through this interface. it is possible for an application to use either a serial or a parallel interface to read out this status report. the serial or parallel mode is selected with the par configuration pin of the ptd (ee section 5.4). the serial interface in 5 samples mode is implemented with 4 signal lines: ? au1s: first status sample input, ? au2s: second status sample input, ? tmc: status clock input, is also used for cpdus and far. ? tmd: status data output, is also used for cpdus and far. when au1s is asserted, the pointer for reading out data with au2s is reset to the second octet of the report. the sample signals au1s and au2s should be asserted as described in figure 15 to fetch the 80 bits of aus report. cpdus, far1s, far2s, aus1s and au2s cannot be asserted simultaneously. if cpdus, far1s, far2s, aus1s and au2s are not asserted, activating the tmc signal will generate invalid data on the tmd output. if the au status report interface is not used, the au1s and au2s signals should be connected to v dd . figure 15 describes the aus telemetry serial interface. serial cpdu, far, au status interface in 2 samples mode the 16 bit command pulse distribution unit status report, the 32 bit frame analysis report and the 80 bit authentication unit status report can be retrieved through this interface. the serial interface in 2 samples mode is implemented with 4 signal lines: ? cpdus: first status sample input, ? far1s: second status sample input, ? tmc: status clock input, ? tmd: status data output. note: the 0 bit is the msb and is transmitted first. figure 14: far telemetry serial interface far1s far2s tmc tmd ptd application telemetry system par = 0 far status report serial interface far i/f 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
ma28140 33/72 note: the 0 bit is the msb and is transmitted first. figure 16: telemetry serial interface in 2 sample mode note: the 0 bit is the msb and is transmitted first. f igure 15: aus telemetry serial interface au1s au2s tmc tmd ptd application telemetry system par = 0 au status report serial interface au i/f bit 0-15 bit 16-31 bit 32-47 bit 48-63 bit 64-79 0 31 0 79 cpdus far1s tmc tmd ptd application telemetry system par = 0 telemetry report serial interface in 2 samples mode
ma28140 34/72 when cpdus is asserted, the pointer for reading out data with far1s is reset to the first octet of the far. the samples cpdus and far1s should be activated as described in figure 16 to fetch the 128 bits of status words. the first 16 bits are those of the cpdu status word, to be acquired by asserting the cpdus signal line. the next 32 bits are those of the far status word, to be acquired by signalling on the far1s signal line (2 x 16 bits). the last 80 bits are those of the au status word, to be acquired by additional assertions (5 x 16 bits) of the far1s signal line. it is possible to read out only the first 48 bits (cpdu and far), e.g. if the au is not used. far1s, au1s and au2s do not have any impact in this mode, but should be connected to v dd . octet (all bits set to 0) on the 8 lsb. for example, if the tc segment to be output is (hexadecimal) aabbcc, the first word read is aabb and the second one is cc00. after a pcsn assertion, the prdy output is activated when the data is available on the pbus output. the prdy is released when the pcsn signal is deasserted. the prdy signal will not be asserted if pcsn is asserted and pad = 000 (map segment read) when mapdsr is inactive. when pcsn is deasserted the pbus bus is tristated. the map status word can be read at any time. the access to this word is identical to the telemetry status word accesses as described in figure 18. it contains the following information: ? pbus<0>: mapdsr information (identical to map data set ready signal line). ? pbus<1>: odd/even segment length information (odd: 1, even: 0). ? pbus<15..2>: not used (value : 00000000000000). note: only tc segments appearing on map 1 to 62 and on map 63 when au is disabled, can be read out using this parallel interface. map 0 is not affected by this parallel interface since it is directly connected to the cpdu. the telemetry status word is read as described in figure 18. the clcw status word is read using one read cycle where pad = 010. the cpdu status word is read using one read cycle where pad = 001. the far status words are read with two read cycles: ? one read cycle with pad = 100 for the first 16 bits (far1) ? one read cycle with pad = 101 for the last 16 bits (far2). the au status words are read using five read cycles: ? one read cycle with pad = 110 for the first 16 bits (au1) ? four read cycles with pad = 111 for the last 64 bits (au2): bits 16-31, bits 32-47, bits 48-63 and bits 64-79. when the au1 status report is read, the pointer for reading out data with au2 is reset to the second octet of the au report. the status of survey bit is set when far2 is read. the following pins have no influence in parallel mode: ? mapdtr (should be connected to v ss ), ? clcwsa, clcwca (should be connected to v dd ), ? au2s (should be connected to v dd ), ? tmc (should be connected to v dd ), ? tmmod (should be connected to v ss ), the reports and tc segments cannot be read out in an arbitrary order. the following constraints apply: a far2 read out shall not be separated from the previous far1 read out by au1 or au2 read out. an au2 read out shall not be separated from a previous au1 or a previous au2 read out by far1 or far2 read out. 5.4 parallel interface a parallel interface is provided on the ptd to access the tc segment and the four reporting words: clcw, cpdus, far and aus. the parallel mode is selected with the par configuration pin of the ptd (the parallel mode is selected when par is set to 1). the parallel interface is implemented with the following signals: ? pcsn: parallel bus chip select input, ? pad<2..0>: parallel address bus (input), ? prdy: data validation output, ? pbus<15..0>: parallel data bus (output), ? mapdsr: map data set ready output, ? mapadt: map aborted data transfer output. the pcsn, pad2, pad1 and pad0 signal lines use respectively the cpdus, far1s, far2s and au1s input pins of the serial interface. the application acquires the tc segment and the four reporting words by read cycles. the addressing of these words is as follows: when the au1 status is read, the pointer for reading out data with au2s is reset. the map tc segment is read as described in figure 17. a tc segment is read by consecutive accesses to <000>. data read when mapdsr is not asserted is not valid. the tc segment data octet of even rank is output on the 8 msb of pbus (the first octet is 00 and therefore even). the tc segment data octet of odd rank is output on the 8 lsb of pbus. in the case of a tc segment with an odd number of octets, the last 16 bits word output on pbus contains the last tc segment data octet on the 8 msb and a non significant pad2 pad1 pad0 read word 0 0 0 map segment 0 0 1 cpdu status 0 1 0 clcw status 0 1 1 map status 1 0 0 far1 status 1 0 1 far2 status 1 1 0 au1 status 1 1 1 au2 status
ma28140 35/72 figure 17: parallel map interface figure 18: parallel telemetry read cycle for a 4 mhz clock, the duration d is 10.24 ms if cpdudiv=0 and 2.048 ms if cpdudiv=1. the maximum duration (=128xd) is about 1.31 s if cpdudiv=0, and 262 ms if cpdudiv=1. the delay between the time at which the packet has been declared legal and the execution of the command instruction (rising edge of cpduen) can be any value between 0.5 d and 1.5 d. the duration between two instructions placed one after the other in the same cpdu packet (from falling edge to rising edge of cpduen) corresponds to about d. 5.5 cpdu interface this interface consists of 3 signal lines: ? cpdustn: cpdu address strobe output, ? cpduen: cpdu enable output, ? cpdudiv: cpdu frequency divider input. the cpdu interface provides the output signal cpdustn in order to save the cpdu physical channel identifier present on the local data bus ldat<7..0> in an external latch (no specific ladr address is associated with this data). this cpdu identifier is used to demultiplex the command pulse toward the selected cpdu output. the cpdustn signal can be controlled by the lack input. the cpduen signal is representative of the command pulse as far as duration is concerned. the pulse amplification should be made after demultiplexing with external circuitry. the cpdudiv signal allows division of the pulse length specified in ref 2 by a factor of 5, in order to get a better accuracy. alternatively, this allows the ptd to be used with a 1mhz clock frequency, instead of a 4 mhz clock. table 4: cpdu pulse lengths command pulse length (clocks) (cpudiv=0) pulse length (clocks) (cpudiv= 1) 000 40961 8193 001 81921 16385 010 163841 32769 011 327681 65537 100 655361 131073 101 1310721 262145 110 2621441 524289 111 5242881 1048577
ma28140 36/72 5.6 local bus interface this interface is used to access the external memory map. it consists of the following signals: ? ladr<10..0>: address bus (output), ? ldat<7..0>: data bus (input/output), ? rwn: read write output, ? lack: memory acknowledge input, ? ramcsn: ram chip select output, ? romcsn: rom chip select output, ? laccs: chip select output asserted for recovery lac counter access. the local bus cycle is started by asserting the rwn and csn signals and activating the ladr signal. it is ended by asserting lack signal. if extended access times are not required, lack can be permanently asserted. this interface provides a bus fault timer which is enabled when csn signals are active and reset when lack signal is active. if a reset doesnt occur within a minimum of 32 tck (8 us for a 4 mhz clock frequency) and a maximum of 64 tck (16 us for a 4 mhz clock frequency), the current local bus cycle is aborted by forcing csn inactive. the functional timings corresponding to the local bus interface are given in section 8.2. figure 19: cpdu interface cpdustn cpduen ldat<7-0> ptd cpdu external module cpdudiv cpdu interface cpdu i/f up to 256 cpdu outputs 5.7 memories the ptd manages two types of memory: ? ram to temporarily store the received tc data and all protocol variables (counter values, programmable key, ...). the ram is organized in 2k words of 8 bits. in the case when it is used to store the eight bits of the recovery lac counter, it should be non volatile. ? rom (1kx8) to store the mission specific data and the fixed authentication key. in order to allow the use of slow memories, an acknowledge signal (lack) is used to indicate when the memory access is completed. in order to save the 8 lsbs of recovery lac counter in a device different from the ram, two different chip select signals (ramcsn and laccs) are provided for the recovery lac counter access. two different modes are provided to manage the lac counter select signals, these modes are selectable with a configuration pin called autsl as follows: ? autsl = 1: the recovery lac counter is stored in ram. the ptd asserts the ramcsn signal when it performs the recovery lac counter access. ? autsl = 0: the recovery lac counter is stored in a device different from the ram. the ptd asserts the laccs signal when it performs the recovery lac counter access. this non volatile memory could be for example an eeprom for low radiation requirements or relays for radiation hardened recovery lacs.
ma28140 37/72 figure 20: recovery lac value storage a diagram of two possible implementations is given in figure 20. the ram mapping is organized in such a way that the ptd is able to use the following external ram buffers: ? two buffers working in a flip-flop mode between transfer and segmentation layer, respectively called front end and back end buffer. ? one buffer used by the cpdu interface the buffer management is described in section 4.2. the memory mapping is defined in tables 5 and 6. ptd ladr ldat 8 rwn ramcsn laccs ad dat we cs ram back-up power vdd vss autsl auext case 1: ram is used to store the 8 bits of recovery lac counter ptd ladr ldat 8 rwn ramcsn laccs ad dat ram non-volatile vss vss autsl auext dat we lac value cs case 2: a device different from the ram is used to store the 8 bits of recovery lac counter we cs
ma28140 38/72 ram start address end address buffer0- ( front end/back end ) ( see note 1 ) 000 0ff buffer1- ( back end/front end ) ( see note 1 ) 100 1ff pro g rammable ke y - knapsack 200 367 pro g rammable ke y - hashin g 368 36f internal use ( reserved ) 370 373 free 374 3ff 8 lsb of recover y lac 400 400 internal use ( reserved ) 401 401 auxiliar y lac counter - octet 4 lsb 402 402 auxiliar y lac counter - octet 3 403 403 auxiliar y lac counter - octet 2 404 404 auxiliar y lac counter - octet 1 msb 405 405 principal lac counter - octet 4 lsb 406 406 principal lac counter - octet 3 407 407 principal lac counter - octet 2 408 408 principal lac counter - octet 1 msb 409 409 free 40a 40f aus octet 10 - buffer 0 410 410 aus octet 9 - buffer 0 411 411 aus octet 8 - buffer 0 412 412 aus octet 7 - buffer 0 413 413 aus octet 6 - buffer 0 414 414 aus octet 5 - buffer 0 415 415 aus octet 4 - buffer 0 416 416 aus octet 3 - buffer 0 417 417 aus octet 2 - buffer 0 418 418 aus octet 1 - buffer 0 419 419 far octet 4 - buffer 0 41a 41a far octet 3 - buffer 0 41b 41b far octet 2 - buffer 0 41c 41c far octet 1 - buffer 0 41d 41d free 41e 42f aus octet 10 - buffer 1 430 430 aus octet 9 - buffer 1 431 431 aus octet 8 - buffer 1 432 432 aus octet 7 - buffer 1 433 433 aus octet 6 - buffer 1 434 434 aus octet 5 - buffer 1 435 435 aus octet 4 - buffer 1 436 436 aus octet 3 - buffer 1 437 437 aus octet 2 - buffer 1 438 438 aus octet 1 - buffer i 439 439 far octet 4 - buffer 1 43a 43a far octet 3 - buffer 1 43b 43b far octet 2 - buffer 1 43c 43c far octet 1 - buffer 1 43d 43d free 43e 5ff cpdu buffer ( see note 2 ) 600 6ff free 700 7ff note 1: the addresses 000 and 100 contain the buffer length (x) and the first word of the frame are stored at address x and 100+x respectively; the last word is stored at address 001 and 101 respectively. note 2: the address 600 contains the cpdu buffer length (x) and the first word of the frame is stored at address 600+x, the last word is stored at address 601. table 5: ram mapping
ma28140 39/72 example an example of rom programming is given here for a fictitious spacecraft. note: in the following example 16# indicates hexadecimal, 10# indicates decimal, 2# indicates binary. the value of the spacecraft id is : 16#301 the value of the virtual channel id is : 16#20 the value of the application process id is : 16#456 for the farm-1 process, the values of pw and nw are : 10#100 and 10#100 the authenication map id pointer is : 16#15 for the cpdu, the application process identifier is : 16#456 frame header octet 1 contains the following fields: version number : 2#00 in accordance with ref 1 bypass flag : 0 or 1 (no influence): 0 for example control comrnand flag : 0 or 1 (no influence): 0 for example reserved field a : 2#00 in accordance with ref 1 spacecraft id (2 msbs) : 2#11 the value of the rom at address 000 is: 16#03 frame header octet 2 contains the following field: spacecraft id (8 lsbs) : 2#00000001 the value of the rom at address 001 is: 16#01 frame header octet 3 contains the following fields: virtual channel id : 2#100000 reserved field b : 2#00 in accordance with ref 1 the value of the rom at address 002 is: 16#80 note 3: these 3 octets contain all the fields of the frame header including reserved bits and version bits. bypass and control flags (in frame header octet 1) form the only field that is not a fixed value: the value of these 2 bits in rom has no influence on the ptd operation (default value = 00). note 4: in order to facilitate the implementation of the farm sliding window concept in the ptd, the values stored in the rom are not pw and nw but: - pw' = pw - 1 - nw' = 256 - nw the pw' and nw' numbers can be any value between 0 and 255. note 5: bits 7 and 6 are not used. note 6: these 2 octets contain all the field of the packet header including version and type bits. note 7: the knapsack key mapping is given in figure 9. address 200 contains the least significant octet of the first knapsack coefficient w0. address 201 contains octet 1 of the first knapsack coefficient w0, (see example below). note 8: the hashing key mapping is given in figure 9. address 368 contains the 4 lsbs of the hashing key stored at the right of the memory octet in the reverse order. address 369 contains the 8 following bits in the reverse order. caution: if the hashing key is read bit by bit starting from the msb, the memory must be filled from right to left, (see example below). table 6: rom mapping rom start address end address frame header octet 1 ( see note 3 ) 000 000 frame header octet 2 ( see note 3 ) 001 001 frame header octet 3 ( see note 3 ) 002 002 farm pw' = pw - 1 ( see note 4 ) 003 003 farm nw' = 256 - nw ( see note 4 ) 004 004 authenticated map id pointer ( see note 5 ) 005 005 cpdu packet header octet 1 and 2 ( see note 6 ) 006 007 free 008 0ff map fre q uenc y table defined in section 5.2 100 13f free 140 1ff fixed ke y - knapsack ( see note 7 ) 200 367 fixed ke y - hashin g ( see note 8 ) 368 36f free 370 3ff
ma28140 40/72 the calculation of pw gives: pw = pw - 1 = 100 - 1 = 99> 16#63 the value of the rom at address 003 is: 16#63 the calculation of nw gives: nw = 256 - nw = 256 - 100 = 156> 16#9c the value of the rom at address 004 is: 16#9b the authenticated map id is 5 bits long. the 5 lsbs of the rom value @ address 05 correspond to the authenticated map id, the 3 msbs can be either 0 or 1 (0 for example). the value of the rom at address 005 is: 16#15 cpdu packet header octet 1 contains the following fields: version number : 2#000 in accordance with ref 1 type : 1 for cpdu data fields header flag : 0 for cpdu application process id (3 msbs) : 2#100 the value of the rom at address 006 is: 16#14 cpdu packet header octet 2 contains the following field: application process id (8 lsbs) : 2#01010110 the value of the rom at address 007 is: 16#56 the rom will be programmed as follows: address data 000 03 001 01 002 80 003 63 004 9c 005 15 006 14 007 56 knapsack and hashing key if the knapsack key is (example from ref.2 appendix b2) w0 : 00 01 02 03 04 05 w1 : 06 07 08 09 0a 0b w59 : 62 63 64 65 66 67 and if the hashing key is : c0...c59 a aa aa aa aa aa aa aa msb the rom will be programmed as follows: address data 200 05 201 04 202 03 203 02 204 01 205 00 206 0b 207 0a etc etc 367 62 368 05 369 55 370 55 etc 55 36e 55 36f 55
ma28140 41/72 5.8 external authentication interface this interface is provided to connect the ptd with an external authentication unit. the ptd allows the external au to access the data buffer (described in section 5.7) of the ram in order to process a tc segment which is to be authenticated. the interface is composed of the following signals: ? audis: (input) this signal functions as for the internal au, disabling the authentication unit. ? auext: (input) this signal indicates the use of an external authentication unit. ? aust: (output) this signal indicates that a tc frame has been received and must be authenticated. in this case, aust is activated a few clock periods after the deactivation of the decod output indicating the end of the tail sequence of the frame. ? aubuf: (output) this signal indicates to the external au which ram buffer is the back-end buffer containing the tc segment to be authenticated. ? brqn: (input) this signal is the bus request to read or write the buffer from the external au. it is activated for each external access to memory. ? bgrn: (output) this signal is the acknowledge of the ptd to brqn; the ptd will then tristate its signals connected to the ram (ramcsn, romcsn, laccs, rwn, ladr and ldat). the lack input has no effect when bgrn output is asserted. ? auend: (input) au result validation. this signal indicates the end of the external authentication process and validates the aur signal. ? aur: (input) au result signal. this signal indicates that the received tc frame is authorized or non authorized at the rising edge of auend. ? autsl: (input) au tail length select signal. this signal allows definition of the length of the au tail as follows: - autsl = 0: the length of the au tail shall be 9 octets. in this case the 9 last octets of the segment authenticated by the external au will be deleted by the ptd before transferring the segment to the application. - autsl = 1: the length of the au tail shall be 0 octets. in this case all octets of the segment authenticated by the external au shall be transfered to the application. ? ausbuf: (output) this signal indicates which au status buffer the external au must update. ? farbuf: (output) this signal indicates which far status buffer the external au must update (the external au shall update only the bits 28 through 30 of the far status). the external au process starts upon receipt of the rising edge of the aust signal, which is asserted by the ptd until the auend input is asserted indicating that the external au process is finished. the result of the external authentication is given by the aur signal (set to 1 for a valid authentication). the total duration of the external au process plus the duration of the map output (if it exists) must be smaller than the duration of the next frame to arrive, measured from the start of the frame to the end of the last valid codeblock. a longer duration may lead to a rise of the farmb wait flag. the result must be given to the ptd before the end of the last valid codeblock of the next frame to arrive, so as not to lock the back-end/front-end buffer toggling mechanism, and the far buffer management of the next frame. the external au can also write the aus status in the local ram, in the buffer number given by the ausbuf output. the ptd locks the toggling mechanism of the au status buffer while aust is high in order to prevent data corruption. the external au can also write bits 28 to 30 of the far status by writing the fourth octet of the far status in the local ram, in the buffer number indicated by the farbuf output. a similar mechanism locks the toggling of the far buffer when the aust output is high. the aus and far buffer update can start when the ptd activates the aust output and shall be completed when the application asserts the auend signal. the local memory interface provides a bus arbiter fault timer. this timer is enabled when bgrn signal is active and reset when brqn signal is inactive. if a reset does not occur within a minimum of 32 tck and a maximum of 64 tck (8 to 16 m s at 4 mhz), the bgrn signal is forced to inactive state. the functional timings corresponding to this interface are given in section 8.2.
ma28140 42/72 6. state after reset asserting the resetn signal asynchronously forces the local bus interface to avoid bus contention. the master clock should be started before resetn deassertion. after 2 master clock cycles, the ptd is in a stable state and all its outputs take their cold start value. deasserting the resetn signal starts the initialisation phase. after this phase, the ptd registers are initialised . ptd outputs after the assertion of resetn input - ladr<10..0> > 000 - ldat<7..0> > zz - rwn > 1 - ramcsn > 1 - romcsn > 1 - laccs > 0 - all other outputs at unknown state ptd outputs after the reset sequence - ladr<10..0> > 000 - ldat<7..0> > zz - rwn > 1 - bgrn > 1 - ramcsn > 1 - romcsn > 1 - laccs > 0 - mapstn > 1 - mapck > 0 - mapdsr > 0 - mapdata > 0 - mapadt > 0 - cpdustn > 1 - cpduen > 0 - clcwda > 0 - tmd > 0 - clcwdb > 0 - prdy > 0 - pbus<15..0> > zzzz - aust > 0 - aubuf > 1 - ausbuf > 0 - farbuf > 0 after reset, 1 after initialization (far write) - seltc<2..0> > 111 - decod > 0 ptd outputs after the initialisation phase coding layer: the coding layer is ready to receive a frame after the reset. transfer layer: the transfer layer initialisation state after reset is the following: ? farm-1 state : lockout ? farmb counter : 11 ? v(r) counter : 00000000 the cold start value of the clcw (2 octets) is x000 (where x can be hexadecimal 2, 6, a or e). the value of the msb (no rf available) depends on the value of the rfavn pin. the value of the second msb (no bit lock) depends on the activation of the tca signals (see section 4.6). authentication layer: the cold start initialisation state for the au layer can be summarized as follows if audis = 0 and auext = 0: - key in use : fixed key - contents of programmable key : undefined - contents of principal and auxiliary lac registers : all ones - contents of the recovery lac counter : unchanged by the ptd
ma28140 43/72 the cold start value of the au status (10 octets) takes the following value if audis = 0 and auext = 0: 3fffffff 7fffffff 00xx in hexadecimal the value of the last octet corresponds to that of the 8 lsbs of the recovery lac, which should be maintained even in the event of loss of power. thus, this value shall be defined during the system implementation. segment layer: the segment layer is ready to receive a new segment. the map outputs are inactive. the cold start value of the far (4 octets) is the following: 00007fe0 in hexidecimal. cpdu layer: the cpdu layer is ready to receive a new cpdu. the cpduen output is inactive. the cold start value of the cpdu status (2 octets) is: 3fff in hexadecimal.
ma28140 44/72 7. signal description in this pin description, first the name of the pin is given, then its type (input (i) or output (o)), and then a brief descript ion. total input pins : 47 total output pins : 51 total i/o pins : 8 total number of input, output and i/o pins : 106 note: bit numbering convention: for busses, the bit number 0 is considered as the least significant bit (lsb). for strobe signals, it is indicated in the text if they are active on low or high level. transponder interface tcc0-tcc5 i symbol clock signals. these signals are only recognised while channel active indication input is asserted. these signals can be asynchronous. tcs0-tcs5 i symbol stream signals. the data should be valid at the falling edge of the tcci signals. these signals can be asynchronous w.r.t. system clock, but not w.r.t. symbol clock signals. tca0-tca5 i channel active indication signals. these signals serve as enable signals for the symbol stream signals. active high. these signals can be asynchronous. local bus interface ladr<10..0> o local address bus . this bus is unidirectional and is tristated when the bgrn signal is asserted. ladr<0> is the lsb. ldat<7..0> i/o data bus - this 8 bit data bus is driven as outputs during write cycles and as inputs during read cycles. this bus is tristated when the bgrn signal is asserted. ldat<0> is the lsb. rwn o read/write signal. this signal indicates the direction of the data transfer on the local bus and is tristated when the bgrn signal is asserted. rwn = 1: read mode. rwn = 0: write mode. lack i memory acknowledge signal. this signal allows wait state cycles to be inserted for memory (ram, rom or lac) read and write access and for cpdustn and mapstn outputs. lack=0 inserts wait states. lack can be permanently connected to 1 when no wait states are required. this signal can be asynchronous. active high. brqn i bus request signal. this signal is asserted by an external unit to request the local bus (external authentication unit for instance). active low. this signal can be asynchronous. bgrn o bus grant signal. this signal is asserted to allow an external unit to use the local bus. active low. ramcsn o ram chip select signal. this signal is asserted during ram access and is tristated when the bgrn signal is asserted. it is affected by the lack input. active low. romcsn o configuration rom chip select signal. this signal is asserted during configuration rom access and is tristated when the bgrn signal is asserted. it is affected by the lack input. active low. laccs o non volatile memory select signal. this signal is asserted during recovery lac counter access and is tristated when bgrn signal is asserted. it is affected by the lack input. active high. map interface mapstn o map address strobe signal. this signal allows the map demultiplexer circuitry to latch the map identifier present on the local data bus. it is affected by the lack input. active low. mapck o map clockout signal. this signal is only activated when both mapdsr and mapdtr signals are active. mapdsr o map data set ready signal. this output indicates that a tc segment is available for transfer. active high. mapdtr i map data terminal ready signal. this signal indicates that the receiving device is ready to clock in the segment data in serial mode or a segment data sample in parallel mode. active high. this signal can be asynchronous. mapdata o map segment data serial line. the segment data is clocked out on the falling edge of the mapck signal. mapadt o map abort data transfer signal. this output is asserted when the ptd has aborted the transfer of a tc segment. active high.
ma28140 45/72 cpdu interface cpdustn o cpdu address strobe signal. this signal allows the cpdu interface to latch the cpdu output address present on the local data bus ldat<7..0>. it is affected by the lack input. active low. cpduen o cpdu enable signal. this signal provides the command pulse with the appropriate duration. active high. cpdudiv i cpdu clock division selection input. cpdudiv = 0: the cpdu base clock (corresponding to d) is the system clock clk divided by 40960. cpdudiv = 1: the cpdu base clock (corresponding to d) is the system clock clk divided by 8192. clcw interface clcwsa i nominal clcw status sample. this signal indicates that the clcw status is sampled by the telemetry interface. active low. this signal can be asynchronous clcwca i nominal clcw status clockout signal. this signal is provided to the ptd when clcwsa signal is active. this signal can be asynchronous clcwda o nominal clcw status data line (serial mode). the data is provided either on the falling edge of clcwsa or on the falling edge of clcwca. clcwsb i redundant clcw status sample. active low. this signal can be asynchronous clcwcb i redundant clcw status clockout signal. this signal can be asynchronous clcwdb o redundant clcw status data line (serial mode). the data is provided on the falling edge of clcwsb or on the falling edge of clcwcb. telemetry interface cpdus/pcsn i cpdu status report sample. this signal indicates that the cpdu status report is sampled by the telemetry interface in serial mode. active low . this signal has the function parallel bus chip select (pcsn) in parallel mode. this signal can be asynchronous far1s/pad2 i far status report first sample. this signal indicates that the first 16 bits of far are sampled in serial mode. active low. this signal has the function bit 2 of parallel address bus (pad2) in parallel mode. this signal can be asynchronous far2s/pad1 i far status report second sample. this signal indicates that the last 16 bits of far are sampled in serial mode. active low. this signal has the function bit 1 of parallel address bus (pad1) in parallel mode. this signal can be asynchronous au1s/pad0 i aus status report first sample. this signal indicates that the first 16 bits of aus are sampled in serial mode. active low. this signal has the function bit 0 of parallel address bus (pad0) in parallel mode. this signal can be asynchronous. au2s i aus status report second sample. this signal is used to read out the last 4 bits of the au staus report by asserting it four times. active low. this signal can be asynchronous. tmc i common status clockout line used for cpdu, far and aus (serial mode). this signal can be asynchronous. tmd o common status data line for cpdu, far and aus (serial mode). the data is provided on the falling edge of cpdus, far1s, far2s, au1s or au2s, or after the falling edge of tmc. parallel interface prdy o parallel interface control line. this output is asserted when the data selected by pad<2...0> is available in parallel mode. active low. pbus<15..0> o parallel interface data bus pbus<15..0> (pbus0 being the lsb). pbus tristate is controlled by the pcsn input. when pcsn is deasserted pbus is tristated.
ma28140 46/72 external authentication unit interface audis i internal au disable signal. this signal allows bypassing of the internal or external authentication unit. the internal and external au are disabled when audis is high. this signal can be asynchronous auext i external au select signal. this signal indicates the use of an external authentication unit. the ptd uses the external au when auext is high and the internal au when auext is low. this signal can be asynchronous aust o au start signal. this signal indicates that a tc frame is received and must be authenticated. it remains active as long as the external au is working; it is deasserted after the activation of the auend input. active high. aubuf o buffer indication signal. this signal indicates which back-end buffer contains the tc segment to be authenticated. aubuf=0: buffer 0 is used aubuf=1: buffer 1 is used. auend i au result validation signal. this signal validates the authentication process result given on pin aur, and indicates the end of the authentication process. this signal can be asynchronous aur i au result signal. this signal indicates that the received tc frame is authorized or not authorized. aur=0 indicates a bad authentication result, aur=1 indicates a valid authentication. this signal can be asynchronous. autsl i au tail length select signal. this signal indicates the length of the tail for segments authenticated with the external au. - autsl = 0: the length of the au tail is 9 octets - autsl = 1: the length of the au tail is 0 octets. if the internal au is selected (auext = 0), this signal defines the implementation of the recovery lac counter: - autsl = 0: the recovery lac counter is stored outside the ram - autsl = 1: the recovery lac counter is stored in the ram. ausbuf o au status buffer. this output indicates which au status buffer that the external au should update. - ausbuf = 0: au status buffer 0 - ausbuf = 1: au status buffer 1. farbuf o far buffer. this output indicates which far status buffer that the external au should update. - farbuf = 0: far status buffer 0 - farbuf = 1: far status buffer 1. miscellaneous rfavn i incoming signal from physical layer, used to generate clcw report. active low. asynchronous. vclsb i virtual channel identifier lsb (static input). this bit enables differentiation between nominal and redundant decoder, even when using the same configuration rom for both decoders. - vclsb = 1: the vc id lsb read from the rom is inverted - vclsb = 0: the vc id lsb read from the rom is not inverted. seltc<2..0> o selected tc channel signals. these outputs indicate the last selected tc channel on which the data present in the back-end buffer was received, it does not concern the cltus being input. seltc<0> is the lsb. decod o decode state signal. this signal indicates that the ptd is in the decode state (active for all bits after the start sequence until and including the tail sequence); it can be used for a scrambler. tmmod i tm mode signal. this static signal allows selection of the telemetry serial mode. - tmmod = 0: the status (cpdus, far, aus) words are fetched with 5 samples - tmmod = 1: the status (cpdus, far, aus) words are fetched with 2 samples. resetn i reset signal. this signal allows the initialization of the ptd. active low. par i parallel or serial interface selecting pin. this static input allows selection of the parallel or serial interface for map data and tm data. - par = 1: parallel mode is selected - par = 0: serial mode is selected. mode i reserved pin. this static input shall be connected to ground. conf i reserved pin. this static input shall be connected to ground. prior i priority mode configuration pin. when this static input is set to 1, the priority mode (tc channels selection) is selected. test i test pin for production test only. this static input shall be connected to ground in functional mode. clk i system clock signal. vdd i +5v (12 pins). vss i ground (14 pins).
ma28140 47/72 8. electrical characteristics and ratings 8.1 dc parameters parameter min max units supply voltage -0.5 7 v input voltage -0.3 v dd +0.3 v current through any pin -20 +20 ma operating temperature -55 125 c storage temperature -65 150 c note: stresses above those listed may cause permanent damage to the device. this is a stress rating only and functional operation of the device at these conditions, or at any other condition above those indicated in the operations section of this specification, is not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. table 7: absolute maximum ratings parameter supply voltage cmos input high voltage cmos input low voltage ttl input high voltage ttl input low voltage output high voltage output high voltage input pull-down current input pull-down current input pull-up current input pull-up current input leakage current output leakage current output leakage current output pull-down current output pull-down current static power supply current dynamic power supply current conditions - - - - - i oh = -3.2ma i ol = 5.0ma v dd = 5.5v, v in = v ss v dd = 5.5v, v in = v dd v dd = 5.5v, v in = v ss v dd = 5.5v, v in = v dd v dd = 5.5v, v in = v ss or v dd v dd = 5.5v, v out = v ss v dd = 5.5v, v out = v dd v dd = 5.5v, v in = v ss v dd = 5.5v, v in = v dd v dd = 5.5v f = 4mhz, v dd = 5.5v typ. 5.0 - - - - - - - - - - - - - - - 0.5 20 symbol v dd v ihc v ilc v iht v ilt v oh v ol i pdl i pdh i pul i puh i l i ozl i ozh i opdl i opdh i dd1 i dd2 min. 4.5 0.8 v dd v ss 2 - 0.9 v dd - -30 -30 -150 -30 -10 -50 -50 -50 -50 - - units v v v v v v v m a m a m a m a m a m a m a m a m a ma ma max. 5.5 v dd 0.2 v dd - 0.8 - 0.1 v dd 30 150 30 30 10 50 50 50 150 20 40 notes: 1. v dd = 5v 10% over full temperature range. 2. total dose radiation not exceeding 10 5 rads(si). 3. mil-std-883, method 5005, subgroups 1, 2, 3. 4. all outputs are suitable for ttl/cmos drive. 5. electro-static discharge protection is provided for all pins. 6. internal pull-up or pull-down resistors should not be relied upon for proper operation and/or termination of input levels under all operating conditions without prior consultation with dynex semiconductor. 7. input and output leakage measurements are guaranteed but not tested at -55 c. t able 8: dc characteristics parameter input capacitance output capacitance conditions v i = 0v v i/o = 0v min. - - typ. 3 5 max. 5 7 units pf pf symbol c in c out note 1: t a = 25?c and f = 1mhz. data obtained by characterisation or analysis; not routinely measured. table 9: capacitance
ma28140 48/72 8.2 ac characteristics symbol f t parameter functionality conditions v dd = 4.5 - 5.5v, freq = 4mhz v il = v ss , v ih = v dd , v ol = v oh = v dd /2 temp. = -55 c to +125 c, gps pattern set mil-std-883 5005 subgroups 7, 8a, 8b table 10: functionality min. - - 100 100 max. 4 - - - units mhz - ns ns symbol fck tck tcl tch typ. - 1/fck - - parameter clock frequency clock period clock low pulse width clock high pulse width notes. 1. t ck will be used as a reference for the timings. 2. for timings specified as a number of clock cycles, it should be noted that there is a variance of 10ns caused by the hold time (for inputs only) and different delays for rising and falling signals. 3. it should be noted that a half clock cycle can mean either the longer or shorter time for a clock not having a duty cycle of 50%. 4. v dd = 5v 10% over full temperature range. 5. total dose radiation not exceeding 10 5 rads (sec). 6. input pulse = v ss to 4v. 7. measurement reference level = 1.5v. 8. output load 1 ttl gate and c l = 50pf. 9. tables 11-25 contain mil-std-883, method 5005, subgroups 9, 10, 11. table 11: clock timings
ma28140 49/72 channel active data stream clock transponder interface ptd rf physical interface transponder : tca timing descri p tion min t yp max ttc1 * tca hi g h to first tcc risin g 4 tck ttc2 * last tcc fallin g to tca low 4 tck ttcclk tcc period 20 m s ttc setup tcs setup to tcc fallin g 0 ns ttc hold tcs hold after tcc fallin g 4 tck * note: if the re q uired timin g is not fulfilled on ttc1 and ttc2, there is a risk of loss of the first or last bits. table 12: physical interface timings
ma28140 50/72
ma28140 51/72 timin g de scri p tion min t yp max tp1 tcc fallin g of the last s y nchro bit to decod risin g 3 tck tp2 tcc fallin g of the last bit of the re j ected codeblock or of the last bit of codeblock number 38 to decod fallin g 3 tck tp3 tca deactivated to decod fallin g 3 tck tp4 timeout on tcc detected to decod fa llin g 3 tck tp5 tca risin g on the channel with hi g her priorit y to decod fallin g 3 tck table 13: decod output timings lower priority channel : tcay
ma28140 52/72 mapdsr mapdtr mapck mapdata mapadt ptd application serial map interface n maximum value is 1991 (=tc segment of 249 octets) example of data transfer with data flow control for each mapdtr pulse one octet is being transferred n maximum value is 1991 (=tc segment of 249 octets) tmaps7 ??? tmaps1 ?
ma28140 53/72 example of an aborted data transfer. table 14: serial map interface timings timin g de scri p tion min t yp max tmapst0 ( 1 ) ( 3 ) mapstn low pulse width 1 tck tmapst1 ldat hold after mapstn risin g 0.5 tck tmapst2 mapst risin g to madsr risin g 2 tck 1 tmapck + 2 tck tmapst3 ldat setup to mapstn fa llin g 0.5 tck tmapst4 mapstn risin g to mapdata valid 2 tck 1 tmapck + 2 tck tmaps1 mapdtr hi g h to mapck risin g 0.5 tmapck 1.5 tmapck + 1 tck tmaps2 ( 3 ) mapck fallin g to mapdsr fallin g 1 tmapck tmaps3 mapdtr setup to mapck fallin g 2 tck tmapck ( 2 ) mapck period 2 tck [2 13 ] tck tmapout mapck fa llin g to mapdata valid -5 ns 10 ns tmapdtr mapdtr hi g h pulse width 2 tck tmap ad t ( 3 ) mapadt hi g h pulse width 2 tmapck tmaps4 ( 3 ) mapck fallin g to mapadt risin g 1 tmapck tmaps5 mapdsr fallin g to mapdsr risin g 56 tck tmaps6 ( 3 ) mapadt risin g to mapdsr fallin g 1 tmapck tmaps7 ( 4 ) mapdsr risin g to mapck risin g 0.5 tmapck 1.5 tmapck note (1): this timing is specified with no wait state configuration (lack permanently asserted). the asserting of this signal is identical with the asserting of the ramcsn signal in a write cycle. note (2): tmapck period is programmable as defined in section 5.2. note (3): these timings are exact with a variance of -10ns to +10ns. note ( 4 ) : this timin g is for a data transfer with mapdtr permanentl y asserted.
ma28140 54/72 clcwsa clcwca clcwda ptd application telemetry system clcw serial interface clcws i/f timin g de scri p tion min t yp max tclcw1 clcwsa fallin g to clcwca fallin g 5 tck tclcw2 clcwca hi g h pulse width between octets 2 tck tclcw3 clcwca setup to clcwsa 0 ns tclcw4 clcwsa hi g h pulse width 3 tck tclcw5 clcwsa fallin g to clcwda valid ( bit 0 ) 4 tck tclcwh clcwca hi g h pulse width tck tclcwl clcwca low pulse width tck tclcwca clcwca period 4 tck tclcwout clcwca fallin g to clcwda valid 1 tck 2 tck note: the same timings apply for the redundant clcw status telemetry interface, which is composed of clcwsb, clcwcb, clcwdb si g nals. table 15: clcw serial interface timings
ma28140 55/72 cpdus tmc tmd ptd cpdu status report serial interface cpdus i/f application telemetry system table 16: cpdus serial interface timings timin g de scri p tion min t yp max tcpdu1 cpdus fa llin g to tmc fallin g 6 tck tcpdu2 tmc hi g h pulse width between octets 2 tck tcpdu3 tmc setup to cpdus 0 ns tcpdu4 cpdus hi g h pulse width 3 tck tcpdu5 cpdus fa llin g to tmd valid ( bit 0 ) 5 tck ttmch tmc hi g h pulse width tck ttmcl tmc low pulse width tck ttmc tmc period 4 tck tcpduout tmc fa llin g to tmd valid 1 tck 2 tck
ma28140 56/72 far1s far2s tmc tmd ptd application telemetry system far status report serial interface far i/f timin g de scri p tion min t yp max tfar1 ( 1 ) fars fallin g to tmc fallin g 16 tck tfar2 tmc hi g h pulse width between octets 2 tck tfar3 tmc setup to fars 0 ns tfar4 far1s risin g to far2s fallin g 2 tck tfar5 far2s risin g to far1s fallin g 4 tck tfar6 ( 1 ) fars fallin g to tmd valid ( bit 0 ) 15 tck ttmch tmc hi g h pulse width tck ttmcl tmc low pulse width tck ttmc tmc period 4 tck tfarout tmc fallin g to tmd valid 1 tck 2 tck note (1): these timings are guaranteed when there is no request for the local bus through the brqn input. in addition when using slow memories, the local memory accesses may be delayed by using the lack input of duration d l ( defined b y the user ) . in this case tfar1 and tfar6 become tfar1+2d l and tfar6+2d l . table 17: far status report serial interface timings
ma28140 57/72 au1s au2s tmc tmd ptd application telemetry system au status report serial interface au i/f timin g de scri p tion min t yp max taus1 ( 1 ) aus fallin g to tmc fallin g 16 tck taus2 tmc hi g h pulse width between octets 2 tck taus3 tmc setup to aus 0 ns taus4 au1s risin g to au2s fallin g 2 tck taus5 au2s risin g to au2s fallin g 2 tck taus6 au2s risin g to au1s fallin g 4 tck taus7 ( 1 ) aus fallin g to tmd valid ( bit 0 ) 15 tck ttmch tmc hi g h pulse width tck ttmcl tmc low pulse width tck ttmc tmc period 4 tck tausout tmc fallin g to tmd valid 1 tck 2 tck note (1): these timings are guaranteed when there is no request for the local bus through the brqn input. in addition when using slow memories, the local memory accesses may be delayed by using the lack input of duration d l ( defined b y the user ) . in this case taus1 and taus6 become taus1+2d l and taus7+2d l . table 18: au status report serial interface timings
ma28140 58/72 pad<2..0> pcsn prdy pbus<15..0> ptd application telemetry system status report telemetry parallel interface tm i/f mapdsr pad<2..0> pcsn prdy pbus<15..0> mapadt ptd application parallel map interface
ma28140 59/72 table 19: parallel map interface timings timin g de scri p tion min t yp max tp1 mapdsr risin g to pcsn fallin g 0 ns tp2 ( 1 ) pcsn fallin g to prdy risin g - for map word ( 1 ) - for clcw word - for cpdu status word - for au and far status word ( 1 ) 2 tck 17 tck 5 tck 7 tck 13 tck tp3 pcsn hi g h width tck tp4 pcsn risin g to prdy fallin g 39 ns tp5 pbus hold after pcsn risin g 0 ns tp6 pbus valid before prdy tck tp7 pcsn risin g to mapdsr fallin g 3 tck 4 tck tp8 mapdsr low pulse width 40 tck tp9 ( 2 ) mapadt hi g h pulse width 2 tck tp10 pad setup to pcsn fallin g tck tp11 pad hold after pcsn risin g tck tp12 ( 2 ) mapadt risin g to mapdsr fallin g tck tp13 pcsn risin g to pbus tristate 31 ns tp14 pcsn fallin g to pbus asserted 0 ns 55 ns note (1): these timings are guaranteed when there is no request for the local bus through the brqn input. in addition when using slow memories, the local memory accesses may be delayed by using the lack input, two extra delays shall be added to tp2. note (2): these timings are exact with a variance of -10ns to +10ns.
ma28140 60/72 cpdustn cpduen ldat<7..0> ptd cpdu external module cpdudiv cpdu interface cpdu i/f table 20: cpdu interface timings timin g de scri p tion min t yp max tc1 ldat setup to cpdustn fallin g 0.5 tck tc2 ( 1 ) ( 2 ) cpdustn low pulse width 1 tck tc3 ldat hold after cpdustn risin g 0.5 tck tc4 cpdustn fallin g to cpduen risin g d/2 - 3 tck tc5 ( 2 ) cpduen fallin g to cpdustn fallin g d/2 + 1 tck tc6 cpduen hi g h pulse width d + tck [2 x ]xd + tck 128d + tck d ( 1 ) cpdudiv = 0 40960 tck d ( 1 ) cpdudiv = 1 8192 tck note (1): this timing is specified with no wait state configuration (lack permanently asserted). the asserting of this signal is identical with the asserting of the ramcsn signal in a write cycle. note ( 2 ) : these timin g s are exact with a variance of -10ns to +10ns.
ma28140 61/72 table 21: memory read timings timin g de scri p tion min t yp max tr1 clk risin g to ladr valid 0 ns 150 ns tr2 clk fallin g to rwn valid 0 ns 57 ns tr3 clk risin g to csn asserted 0 ns 67 ns tr4 clk risin g to csn deasserted 0 ns 68 ns tr5 clk fallin g to rwn invalid 0 ns 57 ns tr6 ldat setup to csn deasserted 100 ns tr7 ldat hold after csn deasserted 0 ns tr8 ( 1 ) lack setup to clk fallin g 20 ns tr9 ( 1 ) lack hold after clk fallin g 20 ns tr10 csn pulse width deasserted 2 tck note ( 1 ) : violation will lead to uncertaint y about the number of wait states inserted.
ma28140 62/72 table 22: memory write timings timin g de scri p tion min t yp max tr12 clk fallin g to ldat valid 0 ns 62 ns tr13 clk fallin g to ldat hi-z 0 ns 40 ns
ma28140 63/72 timin g de scri p tion min t yp max tar1 ( 1 ) brqn fallin g to bgrn fallin g 1.5 tck 2.5 tck tar2 brqn risin g to bgrn risin g 1.5 tck 2.5 tck tar3 bgrn fallin g to local bus hi-z 20 ns tar4 bgrn risin g to local bus driven 20 ns note (1): this timing is dependent on the activity on the local bus. it is defined here for the case when the ptd does not use the local bus. table 23: local bus arbitration timings timin g de scri p tion min t yp max treset1 resetn low pulse width 5 tck treset2 resetn asserted to local bus outputs at cold start values ( 0,1;z ) 60 ns treset3 resetn deasserted to ptd outputs at cold start values ( 0,1;z ) 2 tck treset4 resetn deasserted to end of initialisation phase: ptd functional 200 tck table 24: reset timings
ma28140 64/72 note: in order to use the external authentication unit, the audis and auex signals should be set to 0 and 1 respectively. subgroup 1 2 3 7 8a 8b 9 10 11 table 26: definition of subgroups definition static characteristics specified in table 8 at +25 c static characteristics specified in table 8 at +125 c static characteristics specified in table 8 at -55 c functional characteristics specified in table 10 at +25 c functional characteristics specified in table 10 at +125 c functional characteristics specified in table 10 at -55 c switching characteristics specified in tables 11 to 25 at +25 c switching characteristics specified in tables 11 to 25 at +125 c switching characteristics specified in tables 11 to 25 at -55 c timin g de scri p tion min t yp max tau1 aubuf or ausbuf or farbuf setup to aust risin g 2 tck tau2 auend risin g to aust fallin g 2 tck 3 tck tau3 aubuf or ausbuf or farbuf hold after aust 0 ns tau4 aur setup to auend risin g 2 tck tau5 aur hold after auend risin g 2 tck tau6 aust pulse width deasserted 2 tck tau7 auend pulse width asserted 2 tck table 25: external au interface timings
ma28140 65/72 9. package details 9.1 dimensions ref millimetres inches min. nom. max. min. nom. max. a - - 2.59 - - 0.102 a1 1.37 - 1.88 0.054 - 0.074 b 0.23 - 0.33 0.009 - 0.013 c 0.10 - 0.18 0.004 - 0.007 d1, d2 - - 24.38 - - 0.960 e - - 18.11 - - 0.713 e2 - 20.32 - - 0.800 - e - 0.63 - - 0.025 - l 6.35 - 7.11 0.250 - 0.280 xg533 117 17 83 51 18 50 116 84 e c a a1 d1 l d2 b e e2 pin 1 seating plane top view 132 lead
ma28140 66/72 9.2 pin assignment the type field gives the type of buffer used in the ptd: cmos for cmos input ttl for ttl input 3sta for tri-state output ttl/cmos for ttl/cmos output ttl + 3sta for a bidirectional ttl input associated with a tri-state output the buffer field gives the name of the gps ma9000a buffer used in the ptd: cmosip for input cmos buffer ttlip for input ttl buffer bop for ttl/cmos output buffer triout for output tristate buffer cschmitt for input cmos buffer with schmitt trigger the pu/pd field indicates if an internal pull up or pull down is present in the buffer. note: internal pull-up or pull-down resistors should not be relied upon for proper operation and/or termination of input levels under all operating conditions without prior consultation with gps. transponder interface si g nal p in i/ o t yp e p u/ p d buffer comments tcc0 82 i cmos pu cschmitt s y mbol clock si g nal tcc1 7 9 i cmo s p u cs chmitt " " " tcc2 7 5 i cmo s p u cs chmitt " " " tcc3 7 2 i cmo s p u cs chmitt " " " tcc4 6 8 i cmo s p u cs chmitt " " " tcc5 6 5 i cmo s p u cs chmitt " " " tcs0 81 i cmos pu cschmitt s y mbol stream si g nal tcs 1 7 8 i cmo s p u cs chmitt " " " tcs 2 7 4 i cmo s p u cs chmitt " " " tcs 3 7 1 i cmo s p u cs chmitt " " " tcs 4 6 7 i cmo s p u cs chmitt " " " tcs 5 6 4 i cmo s p u cs chmitt " " " tca0 80 i cmos pd cschmitt channel active indication tca 1 7 7 i cmo s p d cs chmitt " " " tca 2 7 3 i cmo s p d cs chmitt " " " tca 3 7 0 i cmo s p d cs chmitt " " " tca 4 6 6 i cmo s p d cs chmitt " " " tca 5 6 3 i cmo s p d cs chmitt " " "
ma28140 67/72 local bus inte rface si g nal p in i/ o t yp e p u/ p d buffer comments ladr<0> 5 o 3sta triout address bus l a dr<1 > 4 o 3 s ta trio ut " " l a dr<2 > 3 o 3 s ta trio ut " " l a dr<3 > 2 o 3 s ta trio ut " " l a dr<4 > 1 o 3 s ta trio ut " " l a dr<5 > 1 3 2 o 3 s ta trio ut " " l a dr<6 > 1 3 0 o 3 s ta trio ut " " l a dr<7 > 1 2 9 o 3 s ta trio ut " " l a dr<8 > 1 2 8 o 3 s ta trio ut " " l a dr<9 > 1 2 7 o 3 s ta trio ut " " l a dr<1 0 > 1 2 6 o 3 s ta trio ut " " ldat<0> 16 i/o ttl+3sta pd ttlip+triout data bus l da t<1 > 1 5 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<2 > 1 4 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<3 > 1 3 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<4 > 1 1 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<5 > 1 0 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<6 > 9 i/ o ttl +3 s ta p d ttl ip +trio ut " " l da t<7 > 8 i/ o ttl +3 s ta p d ttl ip +trio ut " " rwn 119 o 3sta triout read/write brqn 116 i cmos pu cmosip bus re q uest bgrn 125 o ttl/cmos bop bus grant ramcsn 120 o 3sta triout chip select ram romcsn 121 o 3sta triout chip select rom laccs 122 o 3sta triout recover y lac access lack 115 i cmos pu cschmitt acknowled g e map interface si g nal p in i/ o t yp e p u/ p d buffer comments mapstn 22 o ttl/cmos bop map strobe mapck 25 o ttl/cmos bop map clockout mapdsr 26 o ttl/cmos bop map data set read y mapdtr 36 i cmos pu cschmltt map data term. read y mapdata 28 o ttl/cmos bop map serial data mapadt 23 o ttl/cmos bop map abort data cpdu interface si g nal p in i/ o t yp e p u/ p d buffer comments cpdustn 29 o ttl/cmos bop strobe si g nal cpduen 30 o ttl/cmos bop pulse output cpdudiv 54 i cmos pd cmosip clock dividin g
ma28140 68/72 te le me try inte rface si g nal p in i/ o t yp e p u/ p d buffer comments clcwsa 47 i cmos pu cschmltt clcw status sample clcwca 46 i cmos pu cschmltt clcw status clkout clcwda 32 o ttl/cmos bop clcw status data clcwsb 45 i cmos pu cschmitt redundant clcw clcwcb 44 i cmos pu cschmitt redundant clcw clcwdb 31 o ttl/cmos bop redundant clcw cpdus 43 i cmos pu cschmitt cpdu status sample far1s 42 i cmos pu cschmitt far status first sample far2s 40 i cmos pu cschmitt far status last sample au1s 39 i cmos pu cschmitt au status first sample au2s 38 i cmos pu cschmitt au status second sample tmc 37 i cmos pu cschmitt cpdu/far/au status clk tmd 33 o ttl/cmos bop cpdu/far/au status data p aralle l inte rface si g nal p in i/ o t yp e p u/ p d buffer comments prdy 86 o ttl/cmos bop parallel interface control line pbus<0> 106 o 3sta triout parallel interface data bus pbus<1> 105 o 3sta triout parallel interface data bus pbus<2> 104 o 3sta triout parallel interface data bus pbus<3> 103 o 3sta triout parallel interface data bus pbus<4> 101 o 3sta triout parallel interface data bus pbus<5> 100 o 3sta triout parallel interface data bus pbus<6> 99 o 3sta triout parallel interface data bus pbus<7> 98 o 3sta triout parallel interface data bus pbus<8> 96 o 3sta triout parallel interface data bus pbus<9> 95 o 3sta triout parallel interface data bus pbus<10> 94 o 3sta triout parallel interface data bus pbus<11> 93 o 3sta triout parallel interface data bus pbus<12> 91 o 3sta triout parallel interface data bus pbus<13> 90 o 3sta triout parallel interface data bus pbus<14> 89 o 3sta triout parallel interface data bus pbus<15> 88 o 3sta triout parallel interface data bus authentication interface si g nal p in i/ o t yp e p u/ p d buffer comments audis 109 i cmos pu cmosip internal au b y pass si g nal auext 113 i cmos pd cmosip external au selection aust 84 o ttl/cmos bop au start si g nal aubuf 85 o ttl/cmos bop au buffer si g nal auend 112 i cmos pd cmosip au end validation si g nal aur 111 i cmos pd cmosip au result si g nal autsl 110 i cmos pu cmosip au tail len g th select ausbuf 50 o ttl/cmos bop au status buffer farbuf 49 o ttl/cmos bop far buffer
ma28140 69/72 miscellaneous si g nal p in i/ o t yp e p u/ p d buffer comments rfavn 61 i cmos pu cschmitt ph y sical interface status vclsb 60 i cmos pd cmosip vcid differentiation tmmod 58 i cmos pd cmosip tm mode select par 51 i cmos pd cmosip parallel/serial selection resetn 52 i cmos pu cschmitt reset clk 53 i cmos pu cschmitt clock prior 59 i cmos pd cmosip priorit y mode test 114 i cmos pd cmosip to be connected to vss mode 57 i cmos pd cmosip to be connected to vss conf 56 i cmos pd cmosip to be connected to vss seltc<0> 21 o ttl/cmos bop selected channel seltc<1> 20 o ttl/cmos bop selected channel seltc<2> 19 o ttl/cmos bop selected channel decod 27 o ttl/cmos bop decode state power supply si g nal p in i/ o t yp e p u/ p d buffer comments vdd 6 vdd power suppl y vdd 12 vdd power suppl y vdd 18 vdd power suppl y vdd 35 vdd power suppl y vdd 48 vdd power suppl y vdd 62 vdd power suppl y vdd 76 vdd power suppl y vdd 87 vdd power suppl y vdd 97 vdd power suppl y vdd 107 vdd power suppl y vdd 117 vdd power suppl y vdd 124 vdd power suppl y vss 7 vss power s uppl y vss 17 vss power s uppl y vss 24 vss power s uppl y vss 34 vss power s uppl y vss 41 vss power s uppl y vss 55 vss power s uppl y vss 69 vss power s uppl y vss 83 vss power s uppl y vss 92 vss power s uppl y vss 102 vss power s uppl y vss 108 vss power s uppl y vss 118 vss power s uppl y vss 123 vss power s uppl y vss 131 vss power s uppl y
ma28140 70/72 10. radiation tolerance total dose radiation testing for product procured to guaranteed total dose radiation levels, each wafer lot will be approved when all sample devices from each lot pass the total dose radiation test. the sample devices will be subjected to the total dose radiation level (cobalt-60 source), defined by the ordering code, and must continue to meet the electrical parameters specified in the data sheet. electrical tests, pre and post irradiation, will be read and recorded. gec plessey semiconductors can provide radiation testing compliant with mil-std-883 method 1019 ionizing radiation (total dose) test. 11. ordering information for details of reliability, qa/qc, test and assembly options, see manufacturing capability and quality assurance standards section 9. unique circuit designator s r q h radiation hard processing 100 krads (si) guaranteed 300 krads (si) guaranteed 1000 krads (si) guaranteed radiation tolerance f n flatpack (solder seal) naked die package type qa/qci process (see section 9 part 4) test process (see section 9 part 3) assembly process (see section 9 part 2) l c d e b s rel 0 rel 1 rel 2 rel 3/4/5/stack class b class s reliability level max28140xxxxx total dose (function to specification)* 1x10 5 rad(si) transient upset (stored data loss) 5x10 10 rad(si)/sec transient upset (survivability) >1x10 12 rad(si)/sec neutron hardness (function to specification) >1x10 15 n/cm 2 single event upset** <1x10 -11 errors/bit day latch up not possible * other total dose radiation levels available on request ** worst case galactic cosmic ray upset - interplanetary/high altitude orbit table 27: radiation hardness parameters
ma28140 71/72 12. synonyms ad accepted data frame (accepted by the farm) asic application specific integrated circuit au(s) authentication unit (status) bc bypass control frame bd bypass data frame ccsds consultative committee for space data systems clcw command link control word cltu command link transmission unit cpdu(s) command pulse distribution unit (status) crc cyclic redundant code esa european space agency far frame analysis report farm frame acceptance and reporting mechanism gps gec plessey semiconductors id identifier lac logical authentication channel lfsr linear feedback shift register lsb least significant bit map multiplexed access point msb most significant bit nop no operation nrz(-l) non return to zero (level) n(s) frame sequence number of a transmitted tc frame nw negative window plop physical layer operation procedure psk phase shift keying pss procedures, specification and standards ptd packet telecommand decoder pw positive window ram random access memory rf radio frequency rom read only memory eeprom electrically erasable programmable rom seu single event upset sos silicon on sapphire tc telecommand tm telemetry vc virtual channel vcm virtual channel multiplexer v(r) the next expected tc frame sequence number w farm sliding window width (variable of the farm) 13. applications note 1: failure/problem description the cpdu i/f generates continuously false output signals in the event that "external authentication" and "0 octet au trailers" are used (i.e. audis='0', auext='1' and autsl='1'). this malfunction is particularly critical for applications using the cpdu i/f for its intended purpose to handle emergency situations. after generating a first sequence or correct output signals, the state machine driving the cpdu i/f will get caught in a never-ending loop of states and continue to generate false (pseudo-random) output signals until the ptd is reset by restn='0' or audis='1'. no other command will stop the erroneous outputs of the cpdu i/f. recommended action by users the following combination of signal states must not be used : audis='0', auext='1' and autsl='1'. this can be ensured by either hardwiring on the pcb or appropriate sw provisions. all users are strongly advised to validate the functionality of the cpdu i/f operation for their choice of operation modes.
ma28140 72/72 customer service centre tel: +44 (0)1522 500500. fax: +44 (0)1522 502777 sales office tel: +44 (0)1522 500500. fax: +44 (0)1522 502777 these offices are supported by representatives and distributors in many countries world-wide. ? dynex semiconductor 2001 publication no. ds3839-7 issue no.7.0 september 2001 technical documentation not for resale. printed in united kingdom headquarters operations dynex semiconductor ltd doddington road, lincoln. lincolnshire. ln6 3lf. united kingdom. tel: 00-44-(0)1522-500500 fax: 00-44-(0)1522-500550 dynex power inc. suite 410, 99 bank street, ottawa, ontario, canada k1p 6b9. tel: 613.723.7035 fax: 613.723.1518 toll free: 1.888.33.dynex (39639) this publication is issued to provide information only which (unless agreed by the company in writing) may not be used, applied or reproduced for any purpose nor form part of any order or contract nor to be regarded as a representation relating to the products or services concerned. no warranty or guarantee express or implied is made regard ing the capability, performance or suitability of any product or service. the company reserves the right to alter without prior notice the specification, design or price of any product or service. information con cerning possible methods of use is provided as a guide only and does not constitute any guarantee that such methods of use will be satisfactory in a specific piece of equipment. it is the user's responsibility to f ully determine the performance and suitability of any equipment using such information and to ensure that any publication or data used is up to date and has not been superseded. these products are not suitable for use in any medical products whose failure to perform may result in significant injury or death to the user. all products and materials are sold and services provided subject to the company's conditions of sale, w hich are available on request. all brand names and product names used in this publication are trademarks, registered trademarks or trade names of their respec tive owners. http://www.dynexsemi.com e-mail: space_comms@dynexsemi.com datasheet annotations: dynex semiconductor annotate datasheets in the top right hard corner of the front page, to indicate product status. the annota tions are as follows:- target information: this is the most tentative form of information and represents a very preliminary specification. no actual design work on the product has been started. preliminary information: the product is in design and development. the datasheet represents the product as it is understood but details may change. advance information: the product design is complete and final characterisation for volume production is well in hand. no annotation: the product parameters are fixed and the product is available to datasheet specification.

▲Up To Search▲

Price & Availability of MAQ28140FD

	To Download MAQ28140FD Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .